Software Configuration Management (SCM) Process - Detailed Tasks

Definition

Software Configuration Management (SCM) is the general process of managing a changing software system. During the development process, we have to keep track of the many different versions of each software component and ensure that changes made by different developers do not interfere with each other. SCM is concerned with the policies, processes, and tools for managing changing software systems.

Why SCM is Needed

Software systems are constantly changing during development and after delivery. Multiple developers may work on the same system simultaneously, different versions exist for different customers, and bugs must be fixed while new features are added. Without SCM, chaos results - wrong versions get delivered, changes are lost, and conflicts arise between developers.

Example Context: Consider a team of 5 developers building an Online Banking System. Developer A is fixing a security bug in Login.java, while Developer B is adding a new feature to the same file. Without SCM, one developer's work will overwrite the other's.

Detailed Tasks in SCM Process

Task 1: Change Management

Definition: Change management is the process of keeping track of requests for changes to the delivered software from customers and developers, working out the costs and impact of making these changes, and deciding whether and when the changes should be implemented.

Steps involved:

1. A change request is submitted formally
2. The change is analyzed for cost, impact, and feasibility
3. A Change Control Board (CCB) approves or rejects the change
4. Approved changes are assigned to developers
5. Changes are tracked until completion

Example: In the Online Banking System, a customer requests: "Add UPI payment support."

• A Change Request Form (CRF) is filled out
• The team estimates it will take 3 weeks and affect Payment.java, Transaction.java
• CCB approves the change
• Developer C is assigned the task
• The change is tracked from request to deployment

Task 2: Version Management

Definition: Version management is the process of keeping track of different versions of software components and the systems in which these components are used. It also involves ensuring that changes made by different developers to these versions do not interfere with each other.

Key concepts:

• Version: A specific instance of a software item (e.g., v1.0, v1.1, v2.0)
• Variant: A version created for different environments (e.g., Windows variant, Linux variant)
• Baseline: A snapshot of a system at a particular point in time

Example:

Online Banking System Versions:
- v1.0  --> Initial release (basic login, balance check)
- v1.1  --> Bug fix release (fixed login timeout issue)
- v2.0  --> Major release (added UPI payment support)
- v2.0-Windows --> Windows variant
- v2.0-Android --> Android variant

Tools like Git, SVN, or CVS are used for version management. For example:

git commit -m "Fixed login timeout bug - v1.1"
git tag v1.1
git branch feature/upi-payment   # new branch for v2.0 development

Task 3: System Building

Definition: System building is the process of assembling program components, data, and libraries, then compiling and linking these to create an executable system. Different versions of components may be included in different builds.

Steps involved:

1. Identify which versions of components to include
2. Retrieve those versions from the version management system
3. Compile and link all components
4. Run automated tests on the built system
5. Create a build report

Example:

For the Online Banking System, a build specification might be:

Build: v2.0 Release Build
Components:
  - Login.java         (version 1.3 - security patched)
  - Payment.java       (version 2.1 - UPI added)
  - Transaction.java   (version 1.8)
  - Database.java      (version 1.5)
Build Tool: Maven / Gradle
Command: mvn clean install
Output: BankingApp-v2.0.jar

Build tools like Maven, Gradle, Ant, or Make automate this process. Continuous Integration (CI) tools like Jenkins can trigger automatic builds whenever a developer commits code.

Task 4: Release Management

Definition: Release management involves preparing software for external release and keeping track of the system versions that have been released for customer use. It includes creating the release package (executable, documentation, configuration files) and distributing it to customers.

A release includes:

• The executable programs (compiled code)
• Configuration files
• Data files needed for installation
• Installation programs
• Electronic and paper documentation
• Packaging and associated publicity

Types of releases:

Example:

For the Online Banking System v2.0 release:

Release Package Contents:
- BankingApp-v2.0.jar          (executable)
- config.properties             (configuration file)
- database_schema_v2.sql        (data file)
- install.sh / setup.exe        (installation script)
- UserManual_v2.0.pdf           (user documentation)
- ReleaseNotes_v2.0.txt         (what changed)

The release manager records: "v2.0 released to customers on 2024-01-15, deployed on Linux servers, supports UPI payments."

Summary Table

Conclusion

The four tasks form a single controlled loop. A change request is raised and approved by the CCB, the developer checks out the affected components and checks in new versions under version management, the build process assembles a specific set of those versions into an executable system, and release management packages that build with its documentation and records what was delivered. Because every artefact is versioned and every change is traced back to an approved request, the team can always reproduce any past build of the Online Banking System exactly.