1 / 13

CONFIGURATION MANAGEMENT

CONFIGURATION MANAGEMENT. Today we talk about Software Configuration Management (SCM for short): - What? - Why? - How?. WHY CM?. Multiple people are working on changing software More than one version of the software needs to be supported: Different releases

kessie-shaffer
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 • Today we talk about Software Configuration Management (SCM for short):- What?- Why?- How? Software Engineering 2003 Jyrki Nummenmaa

  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 Software Engineering 2003 Jyrki Nummenmaa

  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 Software Engineering 2003 Jyrki Nummenmaa

  4. SCM Activities • CM data management • Version management- Release versions- Development versions • Concurrent development management • Change management Software Engineering 2003 Jyrki Nummenmaa

  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 Software Engineering 2003 Jyrki Nummenmaa

  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. Software Engineering 2003 Jyrki Nummenmaa

  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. Software Engineering 2003 Jyrki Nummenmaa

  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 -> 1.1 -> 1.2 -> 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. Software Engineering 2003 Jyrki Nummenmaa

  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 -> User is informed • Change is accepted -> go to next slide :) Software Engineering 2003 Jyrki Nummenmaa

  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 :) Software Engineering 2003 Jyrki Nummenmaa

  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 Software Engineering 2003 Jyrki Nummenmaa

  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? Software Engineering 2003 Jyrki Nummenmaa

  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? Software Engineering 2003 Jyrki Nummenmaa

More Related