CONFIGURATION MANAGEMENT

1
CONFIGURATION MANAGEMENT

• Today we talk about Software Configuration
  Management (SCM for short)- What?- Why?- How?

2
WHY CM?

• Multiple people are working on changing software
• More than one version of the software needs to be
  supported
• Different releases
• Different installations with different
  functionalities
• Development versions
• Software needs to run on different operating
  systems and different hardware

3
WHAT IS SCM?

• Configuration management is a way to manage
  evolving software
• Configuration management is a set of disciplines
  and techniques for initiating, evaluating, and
  controlling change to software products.
• Configuration management covers the lifecycle of
  software development

4
SCM Activities

• CM data management
• Version management- Release versions-
  Development versions
• Concurrent development management
• Change management

5
SCM Items

• Design documents
• Code files
• Test data
• Test drivers
• Manuals
• System configuration data
• Etc.
• A meaningful combination of above, meant to be
  treated as a single entity
• Also hardware items can be considered CM Items

6
Managing SCM Items

• There may easily be thousands of SCM items
• A naming scheme should be introduced to identify
  these
• The hierarchical arrangement of software project
  items should be supported
• Should all CM items be managed
• When to start management for an item?
• If you start too early, you get bureaucracy.
• If you start too late, you get chaos.

7
Baselines

• Baseline A specification or a product, which is
  formally reviewed and agreed on, and which can
  only be changed through formal change procedures
• Before an item becomes a baseline, changes can be
  made quickly and informally.
• Baseline is a kind of a milestone in software
  development
• Baseline typically creates new versions in SCIs.

8
Version control

• Procedures and tools to manage different versions
  of configuration objects
• Versions may not always be created in sequential
  order, e.g. you create 1.0 -gt 1.1 -gt 1.2 -gt 2.0
  and then you need to create 1.3 for some
  customers who can not run 2.0 but need some
  changes or improvements.
• With big software, you may e.g have 4.0 as the
  official current version. You work on 5.0 to
  release it as the next official version, but you
  have already started to create 6.0, as it takes
  so long to get it ready.

9
Change Control / 1

• Need for change is recognised
• Someone (like a user) makes a change request
• Developer evaluates
• Change report is generated
• Change control authority decides
• Change is denied -gt User is informed
• Change is accepted -gt go to next slide )

10
Change Control / 2

• 6. Change request is queued for action and and
  engineering change order (technical descr) is
  made
• 7. Assign individuals to make changes to
  configuration objects
• 8. Check out configuration items from project
  repository
• 9. Make the change
• 10. Review (audit) the change
• 11. Check in the changed configuration items
• 12. Establish a baseline for testing the change
• go to next slide )

11
Change Control / 3

• 13. Perform quality assurance (QA) and testing
  activities
• 14. Promote changes for inclusionin next
  release
• 15. Rebuild appropriate version of software
• 16. Review (audit) the change to all
  configuration items
• 17. Include changes in new version
• 18. Distribute the new version

12
SCM Audit / 1

• The following questions should be answered
• Has the change specified in the ECO been made?
  Have any additional modifications been
  incorporated?
• Has formal technical review been conducted to
  assess technical correctness?
• Has the software process been followed and SE
  standards been applied?
• Has the change been appropriately recorded in the
  SCIs?

13
SCM Audit / 2

• More questions to be answered
• 5. Have Software Configuration Management
  procedures for the change been followed?
• 6. Have all related SCIs been properly updated?