More Related Content
Similar to Software Configuration Management
Software Configuration Management
- 1. Software Quality Assurance Session6 – Software configuration Management -Need
- 2. Software configuration Management •Changes to requirements drive the design • Design changes affect the code
- 3. Need for SCM •Think of these – If fully tested program doesn’t work – A difficult bug that was fixed at great expense suddenly reappears
- 4. Without Control • Simultaneous update • Shared code • Common code Problems • Versions Waste enormous amount of time
- 5. Control system • Toanswer the questions – What is my current s/w configuration? – What is its status? – How do I control changes to my configuration? – What changes have been made to s/w? – Do anyone else’s changes affect my software?
- 6. S/w Product Nomenclature Modules Components Products Subsystems System Subsystems Products Components Modules
- 7. Terms in nomenclature • System – package of all software • Subsystem – Large systems into subsystems • Product – all subsystems contain products • Components – next level of product • Module – lowest level – individual functions
- 8. Implementation & building •Implementation – 2 things happen at same time – Modules developed, enhanced, tested & repaired – Modules assembled into components, products, subsystems and systems • Building process – Modules changed to add functions or repair problems
- 9. cont.. • Tests – Unit test – module – Integration test – interfaces & interdependencies – Function test • Component test • Subsystem test • System test – Regression test
- 10. SCM Functions &Responsibilities
- 11. Configuration Management Overview Initial Requirements development /Design/Use Establish/ Approve Update change Baseline Validate Authorize Implement Validate Baseline change change change Baselines Changes
- 12. Basic CM functions • Configuration control • Change management • Revisions • Versions • Deltas • Conditional code
- 13. 1. Configuration Control •Task revolves around one official copy of the code • To protect every system revision – to keep a separate official copy of each revision level. – Lot of storage – Code divergence – Coordination • Solution – keep only one official copy with one common library • Approved changes can be permitted – common library be the official source for all common code
- 14. 2. Revisions • Numberingsystem to identify separately – Test – Module – Component – Product – System • Development – cycle of revision , integration & test
- 15. 3. Derivations • Abilityto determine what has changed Module Module 101 101 Control Program Control Program X Level 116 Level 117 Y Test A Rerun Test A
- 16. 3. Derivations(contd…) • Informationin derivation record – Revision level of each module – Revision level of the tools used to assemble, compile, link, load, and execute the programs & tests – Test cases used & their revision levels – Test data employed – Files used – s/w & h/w system configuration – Operational procedures – If not a stand-alone test, a record of job streams being executed.
- 17. 4. Versions >512 MEML Large Memory MEM MEMS Standard Memory
- 18. 5. Deltas • Versionsintroduces multiple copies of same code • To handle this – Store base module (MEM) together with the changes required it to make it into MEML – When maintenance is required on MEM, can be made directly – no interference with delta code – Similarly to MEML without affecting MEM
- 19. 5. Deltas (contd..) >512 >512 MEML Large Memory MEM MEMS Standard Memory
- 20. 6. Conditional Code Billing NY New York Billing Program Program Billing Connecticut CT Program NY CT PA Billing PA Pennsylvania Program System Generation
- 21. Baselines • Foundation forconfiguration management • Provides the official standard on which subsequent work is based • After an initial baseline is established & frozen, every change is recorded as a delta until the next baseline is set.
- 22. Baseline scope • Forcode control, baseline contains all project code • The items to be included in implementation phase are: – Current level of each module – Current level of each test case – Current level of tools used(compiler, assembler…) – Current level of any special test /operational data – Current level of macros, libraries & files – Current level of installation / operating procedures
- 23. Baseline control • Baselineprotection from unauthorized change • To do this approach in two parts – Locking –charge-out,charge-in procedure – Regression testing
- 24. CM records • Change requse • Change log • Test report • Problem report • Every report has its own contents • Examble – sample change log contents – Change identification • Change number • Date changed – Implementation responsibility • Name, address, phone, organization – Implementation • Source & object code • Documentation • Change dependencies • Tests run & results
- 25. CM Responsibilities • Configurationmanager • Module ownership • Change Control Board (CCB)
- 26. 1. Configuration Manager •Responsibilities – Develop, document & distribute SCM procedures – Establish system baseline including backup provisions – Ensure that no unauthorized changes made to baseline – Ensure all changes are recorded – Ensure all baseline changes are regression tested – Provide the focal point for exception resolution
- 27. 2. Module Ownership •Responsibilities – Know & understand the module design – Provide advice to everyone who works on or interfaces with the module – Serve as technical control point for all module modifications – Ensure module integrity by reviewing all changes & conducting periodic regression tests.
- 28. 3. Change ControlBoard • CCB needs the following information on each proposed change: – Size – Alternatives – Complexity – Schedule – Impact – Cost – Severity – Relationship to other changes – Test – Resources – System impact – Benefits – Politics – Change maturity
- 29. 3. CCB(contd..) • Additionalinformation needed prior to release: – Final source &/ object code for the change – Final documentation changes – Evidence of successful inspection & test of code & documentation