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 stakeholder needs demand modification of data, functionality, or services delivered by a computer-based system
• 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 and tasks that define and effective approach to change management for all stakeholders
• Construction elements – set of tolls that automate the construction of software by ensure a set of validated components is assembled
• Human elements – team uses a set of tools and process features encompassing other CM elements
• 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.
• Baseline work products are place in a project database or repository
SCM Repository Functions
• Data integrity
• Information sharing
• Tool integration
• Data integration
• Methodology enforcement
• Document standardization
• 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
1. Identify all items that define the software configuration
2. Manage changes to one or more configuration items
3. Facilitate construction of different versions of a software application
4. 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)
• Combines procedures and tools to manage the different versions of configuration objects created during the software process
• Version control systems require the following capabilities
o Project repository – stores all relevant configuration objects
o Version management capability – stores all versions of a configuration object (enables any version to be built from past versions)
o Make facility – enables collection of all relevant configuration objects and construct a specific software version
o Issues (bug) tracking capability – enables team to record and track status of outstanding issues for each configuration object
• Uses a system modeling approach (template – includes component hierarchy and component build order, construction rules, verification rules)
• 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
1. Has the change specified by the ECO been made without modifications?
2. Has a FTR been conducted to assess technical correctness?
3. Was the software process followed and software engineering standards been properly applied?
4. Do the attributes of the configuration object reflect the change?
5. Have the SCM standards for recording and reporting the change been followed?
6. Were all related SCI’s properly updated?
Configuration Status Reporting Questions
1. What happened?
2. Who did it?
3. When did it happen?
4. What else will be affected by the change?
WebApp Configuration Issues
• integrating heterogeneous media
• designers often are forced to create content
• content creators often have no software engineering knowledge
• simple WebApps become large quickly
• rigor of configuration control should be proportional to its size
• 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
o converts content to displayable format
o organizes content for client-side display
• Management subsystem
o content database
o database capabilities
o configuration management functions
• Publishing subsystem
o static elements
o publication services
o external services
WebApp Change Classes
• 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 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 reviews by both developers and stakeholders
WebApp Version Control
1. Central repository for WebApp project should be established
2. Each Web engineer should have his or her own working folder
3. Clocks on all developer workstations should be synchronized
4. As new configuration management object as developed or changed they are imported into the repository.
5. A time-stamped log message should be made any time an object is imported or exported from the repository.
Web App 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