Software Configuration Management (SCM)

by Ronni Kahalani, Copenhagen School of Design & Technology.

With inspiration from the book Software Engineering - A Practitioner's Approach.

​

Activities developed to identify change, control change,

ensure that change is being properly implemented and

report changes to others who may have an interest.

​

Who am I?

Thank you for stopping by.

​

I’m Ronni. I hope you’re well and wish you a safe and worthy journey.

​

This presentation is part of the Software Engineering Series, from my lectures at Copenhagen School of Design & Technology.

​

You can view the Introducing Myself, if you want to know a little more about who I am.

​

All my presentations and materials are free and available at my blog post: Software Engineering.

​

​

Don’t let me uphold you,

continue your journey, go to next slide.

2

X /Twitter

@RonniKahalani

�LinkedIn

https://www.linkedin.com/in/kahalani/

�Blog�LearningIsLiving

Agenda

• Intro
• Quick Look
• Software Configuration Management (SCM)
• A SCM Scenario
• Elements of a SCM System
• Baselines
• Branching Strategies
• Software Configuration Item (SCI)
• Management of Dependencies and Changes
• The SCM Repository
• Version Control
• Change Control
• Summary

Intro

SCM activities are developed to:

1. Identify change
2. Control change
3. Ensure that change is being properly implemented
4. Report changes to others who may have an interest

​

Important: A clear distinction between software support and SCM.

SCM is a set of tracking and control activities that are initiated when a software engineering project begins and terminates only when the software is taken out of operation.

Quick Look

• What is it?
• Change to software happens, manage it effectively with a set of activities
• Who does it?
• Everyone involved in the software process to some extent
• 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
• As a consequence, software quality suffers, and delivery is delayed
• Change management is an essential part of quality management

Quick Look

What are the steps?

• Each produced work products must be uniquely identified
• Establish mechanisms for version and change control
• Ensure quality is maintained as changes are made
• The Process is audited and those with a need to know are informed, reporting is conducted

What is the work product?

• SCM Plan defines the project strategy for change management
• The change control process produces change requests, reports, and change orders

How do I ensure that I've done it right?

• When every work product can be accounted for, traced, and controlled

Software Configuration Management (SCM)

The information of output of the software process divided:

• Computer programs.
• Work products that describe the computer programs.
• Data or content .

​

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 SCI (software configuration items) is created.

Software Configuration Management

4 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/downsizing causes changes in project priorities or software engineering team structure
• Budgetary or scheduling constraints cause a redefinition of the system or product

A SCM Scenario

A typical configuration management (CM) operational scenario involves:

• Project Manager: Oversees a software group.
• Configuration Manager: Oversees the CM procedures and policies.
• Software Engineers: Develop and maintain the software product.
• Customer: Uses the product.

An SCM Scenario

At the operational level, the scenario involves various roles/tasks:

• Project Manager: Goal is to ensure that the product is developed within a certain time frame.
• Configuration Manager: Goals 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.
• Software Engineers: Goal is to work effectively
• Customer: Follows formal procedures for requesting changes and for indicating bugs in the product.

An SCM Scenario

Ideally, a CM system used in this scenario should support all these roles and tasks.

• Project Manager: Sees CM as an auditing mechanism
• Configuration Manager: Sees it as a controlling, tracking, and policy-making mechanism.
• Software Engineer: Sees it as a changing, building, and access control mechanism.
• Customer: Sees it as a quality assurance mechanism.

Elements of a SCM System

Susan Dart identifies 4 important element types, that should exist when a configuration management system is developed:

• Components
• Processes
• Constructions
• Humans

​

These elements are not mutually exclusive.

Baselines

IEEE defines a baseline as:

• A milestone in the development of software.
• A specification or product, formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. 
• Is marked by the delivery of one or more (SCIs) - software configuration items that have been approved as a consequence of a technical review.

​

​

Most changes are justified!

Baselines

Baselined SCIs and project database. Most common software base lines.

Baselines

When a team member makes a modification to a base lined SCI, it is copied from a project repository into the engineer's private workspace.�

Process

• Software engineering tasks produce/change one or more SCIs.
• After SCIs are reviewed and approved, they are placed in a project repository.
• Extracted SCI can be modified only if SCM controls are followed.

Branching Strategies

How do we organize our deliveries. What branching strategies are we using?

Branching Strategies

Branch Activities

​

Feat1 merged into DEV (A)

Bug1 & Feat2 pulled (A) from DEV

Bug1 merged into to DEV (AB)

Feat2 pulled (AB) from DEV

Feat2 merged into DEV (ABC)

DEV ABC merged via PR to UAT

UAT ABC merged via PR into MASTER

F hotfix pulled from MASTER

Hotfix merged into MASTER (ABCF)

Bug2 pulled /ABC) from DEV

DEV + UAT updated from MASTER

Bug2 merged into DEV (ABCDF)

Bug2 pulled (ABCDF) from DEV

Bug2 merged into DEV (ABCDEF)

DEV - Main integration

Where everyone deliver their changes, via a PR (pull request) followed by a code review. If you pass, you merge.

Software engineers uses feature branches, named after tickets from a project platform ex. Jira.

UAT - User testing

Where UX, end-users test iteration features in isolation.

When all cceptance test passes UAT is merged into production.

Branch Strategy

​

​

​

​

DEV

UAT

MASTER

Development

Main integration branch, includes latest fixes and features.

User Acceptance Test

Used for testing specific test datasets in isolation.

Production

What our end-customers/users are experiencing, as we speak.

MASTER - Production

Release branches are created off the master branch for final testing and bug fixing before merging into master for production.

​

Software Configuration Item (SCI)

Information that is created as part of the software engineering process.

Software Configuration Item (SCI)

Defined as information that is created as part of the software engineering process.

• SCI is all or part of a work product.
• Many also place software tools under configuration control.
• Specific versions of editors
• Compilers
• Browsers
• and other automated tools are "frozen" as part of the software configuration.

It is possible that a new version of a tool might produce different results than the original version. 

Software Configuration Item (SCI)

SCIs are organized to form configuration objects that may be cataloged in the project database with a single name.

​

Configuration object has a…

• Name
• Attributes
• and is "connected " to other objects by relationships.

​

Notations

• Curved arrow indicates a compositional relation.
• Double-headed straight arrow indicates an interrelationship.

Software Configuration Item (SCI)

If a change were made to the “SourceCode” object, the interrelationships enable you to determine what other objects (and SCIs) might be affected.

Management of Dependencies and Changes

Dependencies needs to be considered when determining the impact of a proposed change and guiding the selection of test cases that should be used for regression testing.

Dependency management can be viewed as impact management.

Impact analysis focuses on organizational behavior as well as individual actions. Impact management involves 2 complementary aspects:

• Ensuring that software developers employ strategies to minimize the impact of their colleagues' actions on their own work.
• Encouraging software developers to use practices that minimize the impact of their own work on that of their colleagues.

Use also bug tracking software and other electronic communication to share undocumented dependencies and problems as they arise!

The SCM Repository

A SCM repository is the set of mechanisms and data structures.

The SCM Repository

SCM repository is the set of mechanisms and data structures.

Provides the obvious functions of a modem database management system by ensuring:

• Data integrity
• Sharing
• Integration

​

In addition:

• Provides a hub for the integration of software tools.
• Is central to the flow of the software process.
• Can enforce uniform structure and format for work products.

The SCM Repository

To achieve these capabilities, repositories are defined in terms of “meta-models”.

​

A meta-model determines:

• How information is stored in the repository.
• How data can be accessed by tools and viewed by software engineers .
• How well data security and integrity can be maintained.
• How easily the existing model can be extended to accommodate new needs.

General Features and Content

Repository features and content are best understood via 2 perspectives:

• What is to be stored in the repository?
• What specific services are provided by the repository?
• A robust repository provides 2 different classes of services:
• The same types of services that might be expected from any sophisticated database management system.
• Services that are specific to the software engineering environment.

​

A repository should also:

• Integrate with or directly support process management functions.
• Support specific rules that govern the SCM function, and the data maintained within the repository.
• Provide an interface to other software engineering tools.
• Accommodate storage of sophisticated data objects (e.g., text, graphics, video, audio).

General Features and Content

SCM Features

To support SCM, the repository must have a tool set that provides support for the following features:

• Versioning.
• Dependency tracking and change management.
• Requirements tracing.
• Configuration management.
• Audit trails.

The SCM Process

It defines a series of tasks that have 4 primary objectives to…

• Identify an items that collectively define the software configuration.
• Manage changes to one or more of these items.
• Facilitate the construction of different versions of an application.
• Ensure that software quality is maintained as the configuration evolves over time.

​

Achieves these objectives need not be bureaucratic and ponderous.

The SCM Process

But it must be characterized in a manner that enables a software team to develop answers to a set of complex questions:

• How does a software team identify the discrete elements of a software configuration?
• How does an organization…
• Manage the many existing versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently?
• Control changes before and after software is released to a customer?
• Assess the impact of change and manage the impact effectively?
• Who has responsibility for approving and ranking requested changes?
• How can we ensure that changes have been made properly?
• What mechanism is used to apprise others of changes that are made?

The SCM Process

These questions lead to the definition of 5 SCM tasks.

• SCM tasks can be viewed as concentric layers
• SCIs flow outward through these layers throughout their useful life, ultimately becoming part of the software configuration of one or more versions of an application or system

​

As an SCI moves through a layer, the actions implied by each SCM task may or may not be applicable.

Layers of SCM Process

Identification of Objects in the Software Configuration

Each SCI should be separately named and then organized using an object-oriented approach. There are 2 types of objects:

• Basic object - a unit of information, created during analysis, design, code, or test.
• Aggregate object - a collection of basic objects and other aggregate objects.

​

Each object has a set of distinct features that identify it uniquely:

Name - Description - List of Resources - Realization

Identification of Objects in the Software Configuration

SCIs er identified via

• Name - a character string that identifies the object unambiguously.
• Description - a list of data items that identify the SCI type.
• Resources - entities that are provided, processed, referenced or otherwise required by the object.
• Realization - a pointer to the “unit of text " for a basic object and null for an aggregate object.

​

The identification scheme for software objects must recognize that objects evolve throughout the software process.

Version Control

Capability that stores and tracks all versions of a configuration object.

Version Control

Implements or is directly integrated with 4 major capabilities:

• Project database (repository)
• Stores all relevant configuration objects.
• Version management
• Capability that stores all versions of a configuration object.
• Make/compile facility 
• Enables to collect all relevant configuration objects and construct a specific version of the software.

​

In addition, version control and change control systems often implement…

• Issues tracking / bug tracking
• Enables the team to record and track the status of all outstanding issues associated with each configuration object.

Version Control

Several version control systems establish a “change set”, required to create a specific version of the software.

​

Dart notes:

“captures all changes to all files in the configuration along with the reason for changes and details of who made the changes and when.”

​

To accomplish this, a “system modelling” approach is applied:

• A template that includes a component hierarchy and a "build order" for the components that describes how the system must be constructed.
• Construction rules.
• Verification rules.

Change Control

Combines human procedures and automated tools,

to provide a mechanism.

Change Control

Too much change control and we create problems. Too little, and we create other problems.

For a large software project, uncontrolled change rapidly leads to chaos.

• Change Control combines human procedures and automated tools to provide a mechanism.

​

Change request is submitted and evaluated to:

• Assess technical merit.
• Potential side effects.
• Overall impact on other configuration objects and system functions.
• Projected cost of the change.

Change Control

The results of the evaluation are presented as a change report, used by:

​

Change Control Authority (CCA)

• A person or group that makes a final decision on the status and priority of the change.

​

Engineering Change Order (ECO) – Is generated for each approved change.

• Describes the change to be made, the constraints that must be respected, and the criteria for review and audit.

​

Change Control

Change Control ("Check out" continued)

Change Control

Version control mechanisms, integrated within the change control process, implement 2 important elements of change management:

• Access control - Governs which software engineers have the authority to access and modify a particular configuration object.
• Synchronization control - Helps to ensure that parallel changes,  performed by 2 different people, don't overwrite one another.

Change Control

Prior to an SCI becoming a baseline, only “informal change control” need be applied.

• Once the object has undergone technical review and has been approved, a baseline can be created.
• Once an SCI becomes a baseline, “project level change control” is implemented.
• Now, to make a change, the developer must gain approval from the project manager (if change is "local ") or from the CCA (Change control authority) if the change affects other SCI

​

When the software product is released to customers, “formal change control” is instituted.

In some cases, the developer dispenses with the formal…

Change Control

Depending on the size and character of a software project, the CCA (Change Control Authority ) may be composed of one person - the project manager - or a number of people.

• The role of the CCA is to take a global view, that is, to assess the impact of change beyond the SCI in question.
• How will the change affect hardware?
• How will the change affect performance?
• How will the change modify customer's perception of the product?
• How will the change affect product quality and reliability?

These and many other questions are addressed by the CCA.

Impact Management

Encompasses the work required to properly understand these interdependencies and control their effects on other SCIs.� - and the people who are responsible for them.

​

Accomplished with 3 actions:

• Impact network - Identifies the members of a software team (and other stakeholders) who might affect or be affected by changes that are made.
• Forward impact management - Assesses the impact of your own changes on the members of the “impact network” and then informs members of the impact of those changes.
• Backward impact management - Examines changes that are made by other team members and their impact on your work and incorporates mechanisms to mitigate the impact.

​

Configuration Audit

How can a software team ensure that the change has been properly implemented? The answer is twofold:

​

Technical reviews

• Focuses on the technical correctness of the configuration object that has been modified.
• Assess the SCI to determine consistency with other SCIs, omissions, or potential side effects.

​

Software configuration audit

• Assessing a configuration object for characteristics

Configuration Audit

The audit asks and answers the following questions:

• Has the change specified in the ECO been made?�Have any additional modifications been incorporated?
• Has a technical review been conducted to assess technical correctness?
• Has the software process been followed and have software engineering standards been properly applied?
• Has the change been "highlighted" in the SCI?�Have the change date and change author been specified?�Do the attributes of the configuration object reflect the change?
• Have SCM procedures for noting the change, recording it, and reporting it been followed?
• Have all related SCIs been properly updated?

Status Reporting

​

Configuration Status Reporting (CSR) also called “status accounting is an SCM task that answers the following questions:

• What happened?
• Who did it?
• When did it happen?
• What else will be affected?

Status Reporting

• Each time an SCI is assigned new or updated identification, a CSR entry is made.
• Each time a change is approved by the CCA (i.e., an ECO is issued), a CSR entry is made.
• Each time a configuration audit is conducted, the results are reported as part of the CSR task.

​

Output from CSR may be placed in an online database or website, so that software developers or support staff can access change information by keyword category.

Summary

Umbrella activity that is applied throughout the software process.

• Identifies, controls, audits, and reports modifications.
• While is being developed and after been released to a customer.
• Organized in a manner that enables orderly control of change.
• Composed of a set of interrelated software configuration items – ‘SCI’.
• Development environment used to create software can also be placed.
• Support information sharing among all members.
• Support of version and change control.

Summary

• Changes to baselined object result in a new version of that object.
• Evolution can be tracked by examining the revision history.
• Change control is a procedural activity that ensures quality and consistency as changes are made to a configuration object
• Change control process begins with a change request.
• Leads to a decision to make or reject.
• Culminates with a controlled update of the SCI that is to be changed.
• The configuration audit is an SQA activity that helps to ensure that quality is maintained as changes are made.
• Status reporting provides information about each change.

Questions?

Anything? What’s on your mind? Come on ask me anything…

​

Feedback?

Thank you for your precious time.

I hope it was worth it and would love to get your feedback.

​

Please share your feedback here