Thorough SCM planning is essential to set up roles, resources, tools, and procedures. The plan addresses:

• Organization – Map responsibilities for SCM tasks like change control
• Resources – Estimate staffing, develop training, select tools
• Scheduling – Coordinate SCM activities with overall project timeline
• Change control – Establish authorities and flows for change requests
• Interface control – Manage changes across internal/external boundaries
• Tool strategy – Evaluate integration, customization, and migration
• Vendor items – Control purchased components like compilers
• Audits – Define product baselines and required formal audits

The SCM plan allows tailoring the process for a specific project while upholding organization standards. It evolves as needs change during the product life cycle.

The team must evaluate functional needs, integration complexity, usability, and cost when selecting a quality SCM tool. Basic capabilities like version control system, change tracking, source control, building, and release management are standard. More advanced needs depend on the project:

• Parallel development – Enable branching, merging, and workspace control
• Distributed teams – Provide access controls and remote coordination
• Variants – Manage builds/releases across multiple platforms
• Formality – Support rigorous workflows and certification
• Customization – Allow adapting tools to organization’s process
• Integration – Interface cleanly with existing engineering environment

Larger benefit from integrated SCM suites rather than individual tools. Cloud services offer configuration management databases (CMDBs) without internal infrastructure costs. Open-source solutions provide flexibility. The team must balance many factors to choose tools that enhance rather than hinder the process.

The initial step is determining which artifacts require configuration management. Software configuration identification analyzes the structure to select configuration items (CIs) meaningful for tracking. Criteria for inclusion are the impact on product build and insight needed for change evaluation. Typical CIs include source code, libraries, scripts, models, documentation, and test artifacts. Outputs from requirements management, design, implementation, and V&V activities become CIs.

Unique identifiers allow precise tracking of CIs as they evolve. Meaningful version numbers and labels help expose the relationships between CIs. The identifier scheme should balance human understanding and tool integration. Items can be assigned globally unique identifiers to avoid collisions. Related CIs may encode hierarchies in a naming convention like “subsystem.module.class”.

Strict identification allows pinpointing the CIs affected by proposed changes – a key enabler of impact analysis. Consistent practices for ID assignment and versioning eliminate ambiguities that lead to integration issues.

A baseline establishes an approved snapshot of a collection of CIs frozen at a point in time. Baselines act as milestones during development, providing a stable reference for continuing work. Typical baselines include requirement specifications, design documents, and test plans. Baselines of source code and compiled executable anchor the build and release process.

Baselines represent the consensus view of the project at key junctures. Changes require formal approval once a baseline is established. The SCM system enforces this by disallowing direct modification of baselined artifacts. Baselines provide checkpoints to gauge progress and rollback points if defects are discovered.

A software library can provide a repository for storing and retrieving controlled versions artifacts. Strict conventions for check-out, modification, and check-in of CIs enable multi-user access and collaboration. The library is the backbone of the build process, ensuring access to the correct CI versions. It also gives definitive storage for deliverable software products and releases.

The library provides traceability through related CIs and baselines. Impact analysis utilizes these links to determine the scope of proposed changes. Powerful querying and reporting mechanisms allow mining this repository for project insights. The library implicitly encodes the history of development decisions through its contents – thus it is an organization asset that persists across.

Read more about software configuration management in the Software Engineer Book of Knowledge (SWEBOK)

Configuration change control manages modifications to baselined CIs. Uncoordinated changes lead to inconsistencies, defects, and uncontrolled CI variations. Formal change control processes avoid these pitfalls. They provide structured flows for proposing, evaluating, and implementing changes based on decision-making authority. Traceability links between change requests, impacted CIs, and new CI versions give visibility into change propagation.

To manage changes, especially in complex, a software configuration control board (SCCB) is established, with decision authority defined proportionate to the risk/impact of the proposed changes. Simple improvements may be approved by individual software engineers, while high-impact changes require full SCCB review.

Developers submit change requests to provide transparency and accountability. Each request is assessed for technical merit, priority, cost, and schedule impact before approval. Approved changes get planned into future baselines/releases. Rejected requests are valuable records of options considered. Change control strikes a balance between agility and oversight.

Change implementation follows a defined process of branching source code files, modifying them, and merging back to the mainline – all while maintaining build integrity. Changes related to a single request may be defined as a development ‘stream’. Parallel changes can be isolated this way while automated testing give rapid feedback on change viability.

Implementation tasks are tracked against the originating change request. Integrations between change management and version control systems streamline change workflow. Traceability links record which CIs and versions implement an approved request. This information anchors the auditing process.

A deviation permits one or more CIs to not meet a requirement for a limited period, whereas a waiver allows permanent non-conformance. For example, a new feature might deviate from the security standard during development, but a waiver could relax the standard to enable faster performance. Deviations and waivers require formal approval – often by the customer – and require tracking as configuration changes. Waivers may indicate the need to update applicable standards for future work.

Configuration status accounting maintains accurate records of each CI as it evolves through baselines and releases. This information provides essential visibility for coordination across the project. It ensures that developers can identify current versions and the relationship between CIs. Build engineers will know precisely which CIs are integrated. Testers can verify that the desired configurations are tested. Finally, management gain insights from change trends, and auditors can confirm that changes followed process .

Careful status accounting avoids confusion that leads to defects and inconsistencies.

Detailed records should capture the key attributes of CIs, baselines, releases, and relationships:

• CI name, description, version, owner
• Baseline membership, date, requirements traceability
• Release contents, platforms, delivery records
• CI relationships like dependency, derivation, and variation
• Change requests linked to CI versions
• Build and test status associated with CIs
• Audit findings attached to CIs/baselines

Collecting this data manually is impractical on large . SCM tools automate status monitoring as changes occur.

Accurate status accounting is wasted without meaningful reporting to technical and managerial stakeholders. Automated reports can provide vital on-demand visibility via several different methods. Dashboards highlight actionable CM metrics, while email alerts might notify of events like baseline establishment. Real-time views reveal current CI versions and dependencies. Traceability reports connect CIs to requirements, and variance reports identify deviations from the plan.

Proactive reporting eliminates blind spots for key decision makers. Software configuration status accounting transforms raw data into operational intelligence.

Software configuration management is essential for coordinating modern software to predictably deliver quality products. SCM provides the rigor to manage changes as software evolves from concept to implementation. Identifying configuration items creates the DNA for controlling versions and understanding the impact of changes. Change request systems make proposed changes visible so they can be assessed. Careful status accounting provides the project snapshot necessary for release management. When enabled by integrated tools and infrastructure, SCM allows distributed teams to collaborate efficiently. Mature software organizations recognize SCM’s vital role and its ability to build long-term organizational capability.

Read more about software configuration management in the Software Engineer Book of Knowledge (SWEBOK)