Configuration Management

1. Configuration Management CIS 376 Bruce R. Maxim UM-Dearborn

2. Configuration Management • New versions of software systems are created as they change • Configuration management is concerned with managing evolving systems • Involves the development of procedures and standards to manage product evolution • May be viewed as part of a more general quality management process

3. Software Configuration Items • Computer programs • both source and executable • Documentation • both technical and user • Data • within a program or external to it

4. Fundamental Sources of Change • New business or market conditions • dictate changes to SW 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

5. Configuration Management Standards • CM should always be based on a set of standards which are applied within an organization • Should define how • items are identified • changes are controlled • versions are managed • Should be based on an evolutionary process model rather than something like the waterfall model

6. 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.

7. 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

8. Software Configuration Objectspart 1 • To control and manage configuration items • each must be named • should be managed using an object-oriented approach • Basic objects • created by software engineers during analysis, design, coding, or testing • Aggregate objects • collections of basic objects and other aggregate objects

9. Software Configuration Objectspart 2 • Configuration object attributes • unique name • description • list of resources • realization (a pointer to a work product for a basic object or null for an aggregate object) • An entity-relationship (E-R) diagram • can be used to show the interrelationships among the objects

10. 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

11. Change Control - part 1 • Change request • 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

12. Change Control - part 2 • Engineering change order (ECO) • 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

13. Change Control - part 3 • 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 • used to ensure that parallel changes made by different people don’t overwrite one another

14. Concurrent Development and Testing • Delivery time is agreed upon for system components • New system version is built from these components • The new version is delivered for testing using predefined tests • Detected faults are documented and returned to system developers

15. Daily System Builds • Allows early detection of component interaction problems • Encourages developers to do thorough unit testing • Developers are under pressure not to “break the build” • Requires the use of a strict management process to track problems that are discovered and repaired

16. Configuration Management Planning • All products of the software process (including documents) may have to be managed • Must start early in project life cycle • Must define formal documents to be managed • Documents which are likely to be used for future system maintenance work should be identified and specified as managed documents

17. Configuration Management Plan • Defines the documents to be managed • Defines who take responsibility for the configuration management procedures and creation of baselines • Defines policies for change control and version management • Defines configuration records to be maintained • Describes the tools that should be used

18. Configuration Database • All configuration management information should be maintained in a configuration database • The database should allow queries like • Who has a particular software version? • What platform is required for a particular version? • What versions are affected by component X changes? • How many reported faults for version Y? • The database should be linked to software being managed (e.g. use of CASE tools)

19. 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?

20. Change Tracking Tools • Major problem in change management is tracking the change status • Change tracking tools help track the status of each change request • Ensures that change requests are sent to the right people at the right time • Can be integrated with e-mail systems to allow electronic distributions of change requests

21. Derivation History • Records changes applied to a document or code component • Should record • change made • rationale for change • who made the change? • when was change implemented? • May be included as comment in the code

22. Version Terminology • Version • instance of system that is functionally distinct from other system instances • Variant • instance of system that is functionally identical but non-functionally distinct from other system instances • Release • system instance distributed to users outside the development team

23. Version and Release Management • Invent identification scheme for system versions • version numbering • attribute-based identification • change-oriented identifications • Plan when new release is to be produced • Ensure that version management procedures and tools are applied properly

24. Version Numbering Derivation Structurefrom Sommerville

25. Attribute-Based Identification • Attributes can be associated with a version • Date • Creator • Programming Language • Customer • Status • More flexible than explicit name for version retrieval (esp. database queries) • Can cause uniqueness problems • Needs an associated name for easy reference

26. Change-Oriented Management • Integrates versions and the changes made to create each version • Used for systems rather than components • Each version has change set that describes the changes used to implement the version • Change sets are applied in sequence so that system versions can be composed by incorporating arbitrary combinations of changes

27. System Releases • Not just a set of executable programs • May also include • configuration files used to define system required for a particular installation • data files needed for system operation • installation shields or shells for specific platforms • electronic and paper documentation • packaging and publicity information

28. System Building Problems • Do the build instructions include all required components? • Is the appropriate version specified for each build component? • Are all data files available? • Are data file references within components correct? • Is system being built for the right platform? • Is the correct versions of the compiler and other tools specified?