1. Configuration Management Why do we need it? What does it do?
Jim Fawcett & Gang Cheng
Brown-Bag Seminar #2
Fall 2004

2. Software Development Effort
Fred Brooks, Program Manager for IBM System/360 and Operating System/360, and later Chair of Computer Science Department, UNC at Chapel Hill, uses this example in his famous “Mythical Man Month”.
Most of us conceive of a program as implementing a specific function, running on the platform on which it was developed. Customers want a program product and often a program system product. Note that there is, by Brooks’ estimate, a nine to one factor in effort required to build the later over the former.
I develop reasonably well tested code at the rate of about 300 lines per day. So for system products I should expect to generate only about 33 lines of code per day - perhaps 2/3 of that in a team environment!
a program
program product
Completely tested
and documented
program system
product
consistent in format
and function with
other programs
X3 effort

3. Large Systems
Here in Syracuse at least two very large software systems have been successfully implemented:
Over The Horizon Radar (OTHR) contained about 3,000,000 lines of code, written mostly in FORTRAN with some C and some assembly language as well.
BSY-2 submarine battle management system software is several times larger than OTHR, written mostly in Ada.
A 5 million line system would require something like:
So, to complete the project in 2.5 years would require the services of at least 380 well trained software developers.
Two points are almost self evident:
a system this large must be partitioned into many relatively small, nearly independent components in order to get it to work
it would be much better not to create such a large system at all, but rather, to build most of it from reused sw components, reserving new code for new requirements.
This can only work if we have an effective system for managing all those components.

4. SW Product Model Architecture – Operational Concept Document
defines product components and allocates processing to them
defines external product behavior
Requirements Specification - SRS
describes what constitutes correct operation
it is the basis for testing and evaluation
Product Specification - SDD
defines an architecture for the system
describes software design and implementation
specifies a software build process
Test Plan
defines procedures for unit, integration, validation, qualification, and regression testing
qualification test procedures are emphasized
Prototype Code
verifies design for critical processing, analyzes implementation problems as they arise
Product Code
Code for each component of the product, implemented as software modules.
test stub attached to each module, used to establish basic software cycling and nearly correct operation
Test Code
test drivers for unit and qualification tests
Test Report
The Architecture
defines a partition of the product into component parts
describes in detail the product’s public interface
lists critical processing
may define major data structures

5. Configuration Management
Configuration management is charged with controlling and providing access to the thousands of documents, code components, and project data items that are generated in a large software development program. Its obligations are:
Identification: Identify every version of every:
document, e.g., specification, design , test, program memo, contract letter, ...
product code component
support and test code component
project data
Each is identified by number, date, and author or responsible individual. It then becomes a configur-ation item.
Baselining: A baseline is a snapshot of the development configuration (all the configuration items) at specific points in the development:
requirements baseline just before SSR
design baseline just before PDR and again before CDR
informal unit test baselines
informal integration baselines
integration test baseline just before TRR
qualification test baseline just before FCA, PCA
Each configuration item must be retrievable from any baseline at any time after the baseline has been constructed.

6. Configuration Management (continued)
Access Control: is intended to insure that all changes to a baseline are properly authorized, all builds have known components, and no baseline becomes corrupted. Access control depends on the type of baseline, e.g.:
formal baselines: The baseline created before each major review, e.g., SSR, PDR, CDR, TRR, PCA are formal and require customer approval to change.
informal baselines: All other baselines require internal approval for change, e.g., the Software Project Manager or his agents, the librarian and team leaders.
Control of the internal baseline is based on role models:
developer may have only read access
team leader has read and write access to the software components being developed by his team
librarian has read and write access to the entire internal baseline, but uses the access as directed by team leaders and the Software Project Manager
Software Project Manager has complete discretion over the internal baseline

7. Configuration Management (continued)
Association: The configuration management system must maintain associations between each component of a baseline for every version. The CM process must be able to answer the questions:
which components where used with any specific build of the hundreds of builds prepared during development?
which of the test data items came from any specific build?
what requirements where identified for a specific build?
what requirements, design, or implementation issues where unresolved for any specific build?
what changes in source code where made between any two builds?
what changes in a document where made between any two releases?
Build Control: The CM system must ensure that a “packing list” of software components is constructed for each build which identifies the specific versions used and test results obtained. The Software Project Manager and Customer must be confident that the version lists and result associations are accurate.

8. Configuration Management (continued)
CM Tools: Maintaining CM integrity requires:
use of database management tools for all but the smallest projects
build control using a testbed with:
command language batch automation
make files
structure libraries based on disk directories organized and access controlled by baseline
extensive requirements trace databases
Independent Validation and Verification (IV&V):
Many contracts demand an IV&V process conducted by a third party (not customer and not developer). Its purpose is to measure and report on:
development process integrity
software quality
IV&V activities are usually carried out by product sampling via inspections, participation in requirements, design, code, and test walkthroughs, and through the evaluation of test plans and test data.
IV&V use the Project’s Configuration Management System intensively, and part of their critique is based on how well the baselines are managed with this tool.

9. Summary Configuration Management
Identification: Names, dates, versions, of items under control
Baselining: Creating a snapshot of everything
Access Control: Preventing unauthorized change.
Association: Establishing relationships between controlled items and key program events.
Build Control: Identifying parts for, and supporting the construction of builds.