CPSC 544: Software Configuration Management (Part I)
Software Configuration Management (SCM) Needs
Fundamental Activity: Change management is critical in software engineering, impacting requirements, design, and code.
Problem Prevention: Poor SCM causes frustrating problems due to conflicting work and lack of coordination among many developers on a project.
Common Problems: Includes simultaneous updates, shared code conflicts, common code modifications, and managing evolutionary releases (versions).
SCM Definition: A set of activities to manage change by identifying likely-to-change work products, establishing relationships, defining version mechanisms, controlling changes, and auditing/reporting.
Software Product Nomenclature
Hierarchical Structure: Systems are partitioned into smaller, manageable units during design and then assembled during implementation.
Levels: System > Subsystem > Product > Components > Module.
Testing: Unit tests for modules, integration tests for interfaces, function tests for operable builds, and regression tests for new builds to ensure no degradation.
Basic SCM Functions
Baselines: An initial stable product level is established as a baseline; subsequent enhancements lead to new baselines. All baselines and changes are retained.
Official Repository: A baseline is a protected, official source containing the most current, tested, and approved version; ensures consistency among developers.
Key Tasks: Configuration control, change management, revisions, versions, deltas, and conditional code.
Configuration Control: Manages an official copy of the code, tracking individual changes.
Revisions: Documenting every change to every module and test case for problem tracing and exact test reproduction.
Derivations: Records detailing revision levels of modules, tools, test cases, data, and system configurations used for tracing changes.
Versions: Managing multiple functional variations of the same module within the repository.
Deltas: Storing a base module with changes required to create another version, useful for temporary variations to avoid duplicate code.
Conditional Code: Using constructions (e.g., system generation options) to include specific code variations based on conditions, avoiding separate modules.
Baselines
Foundation: The baseline provides the official standard for subsequent work, with only authorized changes recorded as deltas until the next baseline.
Establishment: Should be established when integration begins, not too early to avoid unnecessary procedures.
Scope: Includes current levels of modules, test cases, tools, data, macros, libraries, files, and operating procedures.
Control: SCM protects the baseline from unauthorized changes while allowing programmers flexible private working copies for modification and testing.
Records: Documentation of change proposals, change logs, test reports, problem reports (crucial), and expect lists detailing planned functions/features.
SCM Responsibilities
Roles: Configuration manager, Module ownership, and Change Control Board (CCB).
Module Ownership: Assigning a programmer as owner for each module to maintain design integrity, advise, control modifications, and ensure integrity through reviews and regression tests.
Change Control Board (CCB): A central control mechanism for large projects ensuring all baseline changes are properly considered, authorized, and coordinated by representatives from various departments.
CCB Considerations: Evaluates changes based on size, complexity, impact, cost, schedule, severity, test requirements, resources, benefits, and political factors.
CCB Challenges: High workload (may require multiple CCBs) and the need for careful member selection, often chaired by the project manager.
SCM Organization: Coordinates with computer operations to reproduce program/test environments; SCM handles project-unique changes, operations handles system-wide changes.
Automated Tools for SCM
Necessity: Essential for managing the large amount of detail in development, as manual processes lead to errors and quality issues.
Change Management System: Tracks change requests, problem reports, CCB actions, and activity logs. Monitors status, mean time to closure, and backlog, providing project status indicators.
System Library: Stores all development work products (source/object code, test cases, tools). Provides locks, builds various system configurations, retrieves objects, identifies relationships, and gathers statistics.