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. 610.12-1990

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 actionchange request is denied

user is informed

need for change is recognized

Change Control Process—2Change 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


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


• When the software product is released to the customer, formal change control is instituted


• 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


• 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?


• 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

Function Visibility Traceability

Identification •User/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

Control •Current 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

Function Visibility Traceability

Auditing •Inconsistencies 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/Reporting •Reports 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


• 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


• 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


• 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. 828-1983



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

scm

Education

control of change

change reviewaudit

sources of change

change report

change heraclitus

introduction change

justifiable change

access control