Software Configuration Management If you dont control CHANGE

Software Configuration Management • If you don’t control CHANGE, it will control you. • Confusion arises when changes are not analyzed before they are made, recorded, before they are implemented, reported to those with a need to know , or controlled in a manner that will improve quality and reduce error.

What is SCM • Is a set of activities designed to control change by identifying the work products that – Are likely to change – Establish relationships among them – Defining mechanisms for managing different versions of these work products. – Controlling the changes imposed – Auditing and reporting on the changes made

Primary goal of SCM • Is to improve the ease with which changes can be accommodated and reduce the amount of effort expended when changes must be made.

4 fundamental sources of change • • New business or market conditions dictate changes in product requirements or business rules. New customer needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by a computer-based system. Reorganization or business growth/ downsizing causes changes in project priorities or software engineering team structure. Budgetary or scheduling constraints cause a redefinition of the system or product.

Base Lines • Change is a fact of life in software development and a BASELINE is a software configuration management concept that helps us to control change without seriously impeding justifiable change. • IEEE defines a baseline as: – A specification or product that has been formally reviewed and agreed upon, that there after serves as the basis for further development, and that can be changed only through formal change control procedures.

Change control • Change control is vital. But the forces that make it necessary also make it annoying. We worry about change because a tiny alteration in the cade can create a big failure in the product. But it can also fix a big failure or enable wonderful new capabilities. We worry about change because a single rogue developer could sink the project; yet brilliant ideas originate in the minds of those rogues, and a burdensome change control process could effectively discourage them from doing creative work. • The art of progress is to preserve order amid change and to preserve change amid order.

The control process 1. 2. Change request Evaluate change request 1. 3. 4. Assess technical merit, potential side effects, overall impact on other objects, projected cost of the change. Change report is generated Change control authority decides (a person, or group, yes/no, priority etc. . ) 1. 2. If no, inform user is informed If yes, 1. 2. 3. 4. 5. 6. Assign individuals to configuration Make change Review change Test change, and all other objects it touches Perform quality assurance activities Update documentation

How to ensure the change has been properly implemented • . FTR (Formal technical reviews. – Focuses on the technical correctness of the configuration object that has been modified. • Software configuration audit. – Complements the FTR by assessing or focusing on the change specifically • ? ’s to be asked answered – Has the change specified in formal documentation. – Has a formal technical review been conducted to assess technical correctness – Has the software process been followed and have software engineering standards bee properly applied – Has the change been “highlighted” in the priority list? Have the Change date and change author been specified? Do the attributes of the configuration objects reflect the change? – Have SCM(software configuration management) procedures for noting the change, recording it. , and reporting it been followed? – Have all related modules been properly updated.