Changes are inevitable when software is built. A primary goal of software engineering is to improve the ease with which changes can be made to software. Configuration management is all about change control. Every software engineer has to be concerned with how changes made to work products are tracked and propagated throughout a project. To ensure that quality is maintained the change process must be audited. A Software Configuration Management (SCM) Plan defines the strategy to be used for change management.
Software Configuration Items (SCI)
Computer programs (both source and executable)
Documentation (both technical and user)
Data (contained within the program or external to it)
Fundamental Sources of Change
New business or market conditions dictate changes to product requirements or business rules
New customer needs demand modification of data, functionality, or services
Business reorganization causes changes in project priorities or software engineering team structure
Budgetary or scheduling constraints cause system to be redefined
Configuration Management System Elements
Component elements - set of tools coupled within a file management system to enable access to and management of each SCI
Process elements - collection of procedures that define an effective approach to change management for all stakeholders
Construction elements - set of set of tools that automates the construction of software to ensure a set of validated components is assembled
Human elements - team uses a set of tools and process features encompassing other CM elements
Baselines
A work product becomes a baseline only after it is reviewed and approved.
A baseline is a milestone in software development that is marked by the delivery of one or more configuration items.
Once a baseline is established each change request must be evaluated and verified by a formal procedure before it is processed.
SCM Repository Functions
Data integrity
Information sharing
Tool integration
Data integration
Methodology enforcement
Document standardization
SCM Content
Problem description
Problem domain information
Emerging system solution
Software process rules and instructions
Project plan, resources, and history
Organizational content information
SCM Tool Features
Versioning - control changes to all work products before and after release to customer
Dependency tracking and change management - tracking relationships among multiple versions of work products to enable efficient changes (link management)
Requirements tracing - depends on link management, provides the ability to track all work products that result from a specific requirements specification (forward tracing) and to identify which requirement generated by any given work product (backward tracing)
Configuration management - works closely with link management and versioning facilities to keep track of a series of configurations representing project milestones or production releases
Audit trails - establishes additional information about when, where, why, and by whom changes were made
SCM Process Objectives
Identify all items that define the software configuration
Manage changes to one or more configuration items
Facilitate construction of different versions of a software application
Ensure that software quality is maintained as configuration evolves
Software Configuration Management Tasks
Identification (tracking multiple versions to enable efficient changes)
Version control (control changes before and after release to customer)
Change control (authority to approve and prioritize changes)
Configuration auditing (ensure changes made properly)
Reporting (tell others about changes made)
Configuration Object Identification
To control and manage configuration items, each must be named and managed using an object-oriented approach
Basic objects are created by software engineers during analysis, design, coding, or testing
Aggregate objects are collections of basic objects and other aggregate objects
Configuration object attributes: unique name, description, list of resources, and a realization (a pointer to a work product for a basic object or null for an aggregate object)
Class diagrams and evolution graphs can be used to show the interrelationships among the objects
Version Control
Combines procedures and tools to manage the different versions of configuration objects created during the software process
An entity is composed of objects at the same revision level
A variant is a different set of objects at the same revision level and coexists with other variants
A new version is defined when major changes have been made to one or more objects
Change Control
Change request is submitted and evaluated to assess technical merit and impact on the other configuration objects and budget
Change report contains the results of the evaluation
Change control authority (CCA) makes the final decision on the status and priority of the change based on the change report
Engineering change order (ECO) is generated for each change approved (describes change, lists the constraints, and criteria for review and audit)
Object to be changed is checked-out of the project database subject to access control parameters for the object
Modified object is subjected to appropriate SQA and testing procedures
Modified object is checked-in to the project database and version control mechanisms are used to create the next version of the software
Synchronization control is used to ensure that parallel changes made by different people don't overwrite one another
Software Configuration Audit Questions
Has the change specified by the ECO been made without modifications?
Has an FTR been conducted to assess technical correctness?
Was the software process followed and software engineering standards applied?
Do the attributes of the configuration object reflect the change?
Have the SCM standards for recording and reporting the change been followed?
Were all related SCI's properly updated?
Configuration Status Reporting Questions
What happened?
Who did it?
When did it happen?
What else will be affected by the change?
WebApp Configuration Issues
Content
integrating heterogeneous media
volatility
People
designers often are forced to create content
content creators often have no software engineering knowledge
Scalability
simple WebApps become large quickly
rigor of configuration control should be proportional to its size
Politics
Who owns a WebApp?
Who assumes responsibility for accuracy?
Who makes changes?
Who pays for changes?
Content Management System
Establishes a process that acquires existing content, structures it to be presented to an end-user, and provides for display to the client-side environment
Collection subsystem
converts content to displayable format
organizes content for client-side display
Management subsystem
content database
database capabilities
configuration management functions
Publishing subsystem
static elements
publication services
external services
Agile WebApp Change Management
Code and go philosophy dominates WebApp development
Class 1 and 2 changes are treated informally and are handled in an agile manner
Class 2 changes require an impact study
Class 3 and 4 changes are handled in and agile manner, but some documentation and more formal change review procedures are required
Class 3 changes are reviewed by developers
Class 4 changes are reviewed by both developers and stakeholders
Class 1 - content or function change to correct error or enhance local content or functionality
Class 2 - content or function change that has impact on other content objects or functional components
Class 3 - content or function change that has broad impact across WebApp
Class 4 - major design change that will be noticeable to one or more categories of user
WebApp Version Control
Central repository for WebApp project should be established
Each Web engineer should have his or her own folder
Clocks on all developer workstations should be synchronized
As new configuration management object as developed or changed they are imported into the repository.
A time-stamped log message should be made any time an object is imported or exported from the repository.
WebApp Auditing and Reporting
In the interest of agility auditing and reporting functions are deemphasized
Changes can be tracked by reviewing the change log
Automatic e-mail messages can be used to notify affected stakeholders when changes are made
