SCM

Introduction Change is inevitable when software is built Change increases the level of confusion Confusion arises when changes are not –Analyzed before they are made –Recorded before they are implemented –Reported to those who need to know –Controlled in a manner that will improve quality and reduce error

SCM - 1 The art of coordinating software development to minimize confusion is called configuration management. Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team The goal is to maximize productivity by minimizing mistakes

SCM - 2 Software configuration management is an umbrella activity, which provides a cover against –Lack of visibility –Lack of control –Lack of traceability –Lack of monitoring –Uncontrolled change

SCM - 3 Software configuration management provides a means for visibility, traceably, and formally controlling the evolution of software

Software Configuration The items that comprise all information produced as part of the software process are collectively called a software configuration –Computer programs (source and executable) –Documents that describe the computer programs –Data Software configuration items will grow

Change - A Constant There is nothing permanent except change –Heraclitus (500 B.C.) No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle Software is like a sponge due to its susceptibility to change

Sources of Change - 1 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 computer-based system

Sources of Change - 2 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

Change is Everywhere Customers want to modify requirements Developers want to modify the technical approach Managers want to modify the project strategy

Why All This Modification? As time passes, all constituencies know more –About what they need –Which approach would be best –How to get it done and still make money Statement of the fact: Most changes are justified!

How to Manage Change? A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change

Baseline A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures –IEEE Std. No

SCM Functions The four software configuration management functions are –Identification –Control –Auditing –Status accounting/reporting

SCM Function: Identification Each software part is physically labeled, according to SCM plan

SCM Function: Control Proposed changes to software parts are reviewed, then subjected to the agreement of project participants, and finally incorporated into the currently approved software configuration Two types of control –Version control –Change control

Version Control Configuration management allows a user to specify alternative configurations of the software system through the selection of appropriate versions. This is supported by associating attributes with each software version, and then allowing a configuration to be specified [and constructed] by describing the set of attributes

Change Control - 1 Change control is vital Too much change control and we create problems. Too little, and we create other problems The art of progress is to preserve order amid change and to preserve change amid order –Alfred North Whitehead

Change Control - 2 For large projects, uncontrolled change rapidly leads to chaos For large projects, change control combines human procedures and automated tools to provide a mechanism for the control of change

The Change Control Process - 1 change request from user developer evaluates change report is generated change control authority decides request is queued for action change request is denied user is informed need for change is recognized Change Control Process—2

The Change Control Process - 2 assign people to SCIs check-out SCIs make the change review/audit the change establish a “baseline” for testing Change Control Process—3

The Change Control Process - 3 perform SQA and testing activities promote SCI for inclusion in next release rebuild appropriate version review/audit the change include all changes in release check-in the changed SCIs

Access and Synchronization Control - 1 Confusion leads to errors - some of them very serious Access and synchronization control avoid confusion. Implement them both

Access and Synchronization Control - 2 Access control governs which software software engineers have the authority to access and modify a particular configuration object Synchronization control helps to ensure that parallel changes, performed by two different people, don’t overwrite one another

Change Control Issues - 1 Without proper safeguards, change control can retard progress and create unnecessary red tape Prior to an SCI becoming a baseline, only informal change control need be applied Once SCI is in a baseline, project level change control is implemented

Change Control Issues - 2 When the software product is released to the customer, formal change control is instituted

Change Control Issues - 3 Change control authority/board assesses the impact of change beyond the SCI in question –How will the change affect hardware? –How will the change affect performance? –How will the change modify customer’s perception of the product? –How will the change affect product quality and reliability?

SCM Function: Auditing - 1 How can we ensure that the approved changes have been implemented? –Formal technical reviews Focus on the technical correctness of the modified object. The reviewers assess the SCI to determine consistency with other SCIs, omissions, or potential side effects –Auditing

SCM Function: Auditing - 2 Has the change specified in the ECO been made? Have any additional modifications been incorporated? Has a formal technical review been conducted to assess technical correctness? Has the software process been followed and have software engineering standards been properly applied?

SCM Function: Auditing - 3 Has the change been “highlighted” in the SCI? Have the change date and change author been specified? Have SCM procedures for noting the change, recording it, and reporting it been followed? Have all related related SCIs been properly updated?

SCM Function: Status Accounting/Reporting The status accounting function provides a corporate memory of project events that supports accomplishment of three other configuration management items –What happened? –Who did it? –When did it happen? –What else will be affected?

SCM Functions Infuse Visibility and Traceability - 1 FunctionVisibilityTraceability IdentificationUser/buyer/seller can see what is being/has been built/is to be modified Management can see what is embodied in a product All project participants can communicate with a common frame of reference Provides pointers to software parts in software products for use in referencing Make software parts and their relationships more visible, thus facilitating the linking of parts in different representations of the same product ControlCurrent and planned configuration generally known Management can see impact of change Management has option of getting involved with technical detail of project Makes baselines and changes to them manifest, thus providing the links in a traceability chain Provides the forum for avoiding unwanted excursions and maintaining convergence with requirements

SCM Functions Infuse Visibility and Traceability - 2 FunctionVisibilityTraceability AuditingInconsistencies and discrepencies manifest State of product known to management and product developers Potential problems identified early Checks that parts in one software product are carried through to the subsequent software produc Checks that parts in a software product have antecedents in requirements documentation Status Accounting/ReportingReports inform as to status Actions/decisions made explicit (eg., through CCB meeting minutes) Database of events is project history Provides history of what happened and when Provides explicit linkages between change control forms

Real World Considerations - 1 Management Commitment –Management commitment to the establishment of checks and balances is essential to achieving benefits from SCM SCM Staffing –Initial staffing by a few experienced people quickly gains the confidence and respect of other project team members

Real World Considerations - 2 Establishment of a CCB –As a starting point in instituting SCM, periodic CCB meetings provide change control, visibility, and traceability CM During the Acceptance Testing Cycle –CM integrated within the acceptance testing cycle maintains a visible and traceable product ready for delivery to the customer

Real World Considerations - 3 Justification and Practicality of Auditing –Although the auditing consumes the greater part of the SCM budget, it has the potential of preventing the waste of much greater resources Avoiding the Paperwork Nightmare –The buyer/user and seller should agree on the paperwork needed to achieve a mutually desirable level of visibility and traceability

Real World Considerations - 4 Allocating Resources among CM Activities –Cost versus benefits must be evaluated for each individual project in determining the allocation of limited SCM resources

SCM Standards MIL-STD-483 DOD-STD-480A MIL-STD-1521A ANSI/IEEE Std. No ANSI/IEEE Std. No ANSI/IEEE Std. No

Conclusion Software configuration management is an umbrella activity that is applied throughout the software process SCM identifies, controls, audits, and reports modifications that invariably occur while software is being developed and after it has been released SCM saves a project from total chaos

References Software Engineering: A Practitioner’s Approach by Roger S. Pressman A Handbook of Software Quality Assurance edited by G. Gordon Schulmeyer and James L. McManus Customer-Oriented Software Quality Assurance by Frank P. Ginac Software Quality: Analysis and Guidelines for Success by Capers Jones