Software configuration Management• Changes to requirements drive the design• Design changes affect the code
Need for SCM• Think of these – If fully tested program doesn’t work – A difficult bug that was fixed at great expense suddenly reappears
Without Control• Simultaneous update• Shared code• Common code Problems• Versions Waste enormous amount of time
Control system• To answer 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?
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
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
cont..• Tests – Unit test – module – Integration test – interfaces & interdependencies – Function test • Component test • Subsystem test • System test – Regression test
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
2. Revisions• Numbering system to identify separately – Test – Module – Component – Product – System• Development – cycle of revision , integration & test
3. Derivations• Ability to determine what has changed Module Module 101 101 Control Program Control Program X Level 116 Level 117 Y Test A Rerun Test A
3. Derivations(contd…)• Information in 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.
4. Versions >512 MEML Large MemoryMEM MEMS Standard Memory
5. Deltas• Versions introduces 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
5. Deltas (contd..) >512>512 MEML Large MemoryMEM MEMS Standard Memory
6. Conditional Code Billing NY New York Billing Program Program Billing Connecticut CT ProgramNY CT PA Billing PA Pennsylvania Program System Generation
Baselines• Foundation for configuration 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.
Baseline scope• For code 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
Baseline control• Baseline protection from unauthorized change• To do this approach in two parts – Locking –charge-out,charge-in procedure – Regression testing
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
CM Responsibilities• Configuration manager• Module ownership• Change Control Board (CCB)
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
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.
3. Change Control Board• 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
3. CCB(contd..)• Additional information needed prior to release: – Final source &/ object code for the change – Final documentation changes – Evidence of successful inspection & test of code & documentation