37 Software Change Management

R. Baskaran

SOFTWARE CHANGE MANAGEMENT

Software change management is a process of identifying changes that are to be done in the software. It facilitates and controls making changes to the software for the effective development of the project.

LEARNING OBJECTIVES

To have a birds-eye view of the entire IT infrastructure
To respond, manage and track requests for IT changes using standardized procedures
Assess the cost of proposed changes before they are incurred.
Have fewer changes that are aborted, or fail.
Increase productivity of key personnel through decreased urgent changes.

Quotes

You work for an organization that is spending millions of dollars on a very important new process that will completely change how you work, and who you work with and require you to think about your job in a totally new way. The success of the company depends on you and your co-workers.

Nestle executive in a 2002 interview with CIO magazine the executive summarized what the company had learned. “No major software implementation is really about software. It’s about change management. When you move to SAP, you are changing the way people work. You are challenging principles, their beliefs and the way they have done things for many years”

CHANGE MANAGEMENT

Change management is a planned approach to integrating change which includes formal processes for assessing the impact of the change on both the people it affects and the way they do their jobs. The application of techniques gains acceptance and understanding of the change and change in behavior takes advantage of the new functionality. Change is the interplay among various forces that are involved in growing something new. Deep change comes only through real growth i.e. through learning and unlearning. 70% of all change initiatives fail due to failure to address human component of change.

Implementation of large scale business transformation initiatives, like SAP, by nature result in significant and fundamental change such as;

Changes in the job of the people
Change in job and work content.
Change in the people you work with.
The tools (systems, reports, etc.) of the job and how people interface with them change.
Implementing the initiative requires additional, unfamiliar work, maybe in unfamiliar locations.
New skills, behaviors will be required.
Employee assignment.
Controls (over process and information) will change.
Change in information that is provided, accessed, and shared.

Change management helps determine how people will react to these changes, and therefore, the ultimate success of the transformation of the vision, knowledge, & responsibility.

Software Change Management is also called software configuration management (SCM). It is an umbrella activity that is applied throughout the software process. The goal is to maximize productivity by minimizing mistakes caused by confusion when coordinating software development. SCM identifies, organizes, and controls modifications to the software being built by a software development team. SCM activities are formulated to identify change, control change, ensure that change is being properly implemented, and report changes to others who may have an interest.

SCM is initiated when the project begins and terminates when the software is taken out of operation. View of SCM from various roles

◦ Project manager – an auditing mechanism.

◦ SCM manager – a controlling, tracking, and policy making mechanism.

◦ Software engineer – a changing, building and access control mechanism.

◦ Customer – a quality assurance and product identification mechanism.

Software Configuration

The output from the software process makes up the software configuration:

Computer programs (both source code files and executable files).
Work products that describe the computer programs. (documents targeted at both technical practitioners and users)
Data (contained within the programs themselves or in external files).

The major danger to a software configuration is change. First Law of System Engineering 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.”

Origins of Software Change

Software change originated when errors detected in the software need to be corrected. New business or market conditions dictate changes in product requirements or business rules. Software changes occur when new customer needs demands 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.

Configuration Management System – Elements

Configuration elements include a set of tools coupled with a file management (e.g., database) system that enables access to and management of each software configuration item.

Process elements comprises of a collection of procedures and tasks that define an effective approach to change management for all participants.

Construction elements consist of a set of tools that automate the construction of software by ensuring that the proper set of valid components (i.e., the correct version) is assembled.

Human elements are a set of tools and process features used by a software team to implement effective SCM.

Baseline for SCM

The baseline for SCM concept focuses on helping practitioners to control change without seriously impeding justifiable change.

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

It is a milestone in the development of software and is marked by the delivery of one or more Computer Software Configuration Items (CSCIs) that have been approved as a consequence of a formal technical review.

Baseline Process

The baseline process involves the following;

1) A series of software engineering tasks produces a CSCI.

2) The CSCI is reviewed and possibly approved.

3) The approved CSCI is given a new version number and placed in a project database (i.e., software repository).

4) A copy of the CSCI is taken from the project database and examined/modified by a software engineer.

5) The baseline of the modified CSCI goes back to Step #2.

Automated SCM Repository

Functions of an SCM Repository

Data integrity – It validates entries, ensures consistency, cascades modifications.
Information sharing – It shares information among developers and tools, manages and controls multi-user access.
Tool integration – It establishes a data model that can be accessed by many software engineering tools, controls access to the data.
Data integration – It allows various SCM tasks to be performed on one or more CSCIs.
Methodology enforcement – It defines an entity-relationship model for the repository that implies a specific process model for software engineering.
Document standardization – It defines objects in the repository to guarantee a standard approach for creation of software engineering documents.

Primary Objectives of the SCM Process

The Primary Objectives of the SCM Process includes;

Identification of all items that collectively define the software configuration.
Manage changes to one or more of these items.
Facilitate construction of different versions of an application.
Ensure the software quality is maintained as the configuration evolves over time.
Provide information on changes that have occurred.

SCM

Software change management focuses on addressing the following issues;

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?
How an organization control changes does before and after software is released to a customer?
Who has responsibility for approving and ranking changes?
How can we ensure that changes have been made properly?
What mechanism is used to apprise others of changes that are made?

SCM TASKS

• Concentric layers (from inner to outer)

• Identification

• Change control

• Version control

• Configuration auditing

• Status reporting

• CSCIs flow outward through these layers during their life cycle.

• CSCIs ultimately become part of the configuration of one or more versions of a software application or system.

Identification Task

Identification separately names each CSCI and then organizes it in the SCM repository using an object-oriented approach. Objects start out as basic objects and are then grouped into aggregate objects. Each object has a set of distinct features that identifies it such as a name that is unambiguous to all other objects, a description that contains the CSCI type, a project identifier, and change and/or version information, a list of resources needed by the object and object realization (i.e., the document, the file, the model, etc.)

Change Task

Change control is a procedural activity that ensures quality and consistency as changes are made to a configuration object. A change request is submitted to a configuration control authority, which is usually a change control board (CCB). The request is evaluated for technical merit, potential side effects, overall impact on other configuration objects and system functions, and projected cost in terms of money, time, and resources.

An engineering change order (ECO) is issued for each approved change request. It describes the change to be made, the constraints to follow, and the criteria for review and audit. The baseline CSCI is obtained from the SCM repository where access control governs which software engineers have the authority to access and modify a particular configuration object. The Synchronization control helps to ensure that parallel changes performed by two different people don’t overwrite one another.

Version Control Task

Version control is a set of procedures and tools for managing the creation and use of multiple occurrences of objects in the SCM repository. Required version control capabilities include;

A SCM repository that stores all relevant configuration objects.
A version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions).
A make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software.
Issues tracking (bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.

The SCM repository maintains a change set. It serves as a collection of all changes made to a baseline configuration and is used to create a specific version of the software. It captures all changes to all files in the configuration along with the reason for changes and details of who made the changes and when the changes were made.

Configuration Auditing Task

Configuration auditing is an SQA activity that helps to ensure that quality is maintained as changes are made. It complements the formal technical review and is conducted by the SQA group. It addresses the following questions

Has the change specified in the ECO been made? Have any additional modifications been incorporated?
Has a formal 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” and “documented” in the CSCI? Have the change data 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 CSCIs been properly updated?

A configuration audit ensures that the correct CSCIs (by version) have been incorporated into a specific build and all the documentation is up-to-date and consistent with the version that has been built.

Status Reporting Task

Configuration status reporting (CSR) is also called status accounting. It provides information about each change to those personnel in an organization with a need to know. It addresses the questions and answers what happened, who did it, when did it happen, and what else will be affected. The sources of entries for configuration status reporting occurs when each time a CSCI is assigned new or updated information, each time a change is approved by the CCB and an ECO is issued and each time a configuration audit is conducted. The configuration status report is placed in an on-line database or on a website for software developers and maintainers to read. It is given to management and practitioners to keep them appraised of important changes to the project CSCIs.

Web Links

https://www.prosci.com/change-management/what-is-change-management
https://www.mindtools.com › Project Management › Change Management
https://hbr.org/topic/change-management

Supporting & Reference Materials

David Tuffley “Software Configuration Management: A how to guide for project staff”, create space independent publishing platform, 2011.
Pankaj Jalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag, 1997.
Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000.
https://files.ifi.uzh.ch/rerg/amadeus/teaching/courses/software_engineering_hs07/folien/ch23- SCM-addendum.pdf