Configuration Management CIS 376 Bruce R Maxim UM Dearborn 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 Software Configuration Items Computer programs both source and executable Documentation both technical and user Data within a program or external to it 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 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 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 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 Software Configuration Objects part 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 Software Configuration Objects part 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 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 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 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 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 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 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 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 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 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 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 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 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 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