1 / 28

Configuration Management

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

suzuki
Download Presentation

Configuration Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related