Presentation is loading. Please wait.

Presentation is loading. Please wait.

Configuration Management

Similar presentations

Presentation on theme: "Configuration Management"— 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 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

9 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

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 Change report
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 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 Variant Release
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 Structure from 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?

Download ppt "Configuration Management"

Similar presentations

Ads by Google