adapted from software engineering, 6th edition. chapter 29, by ian sommerville slide 1 configuration...

Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 1

Configuration and Change Management

Managing the products of system change


Topics covered Configuration management fundamentals Software and documentation version control Configuration management planning (SCMP) Change management System building CASE tools for configuration management


New versions of software systems are created as they change For different machines/OS Offering different functionality Tailored for particular user requirements

Configuration management is concerned with managing evolving software systems System change is a team activity CM aims to control the costs and effort involved in making

changes to a system

Configuration Management


Configuration Items (CI’s)

Units tracked officially down to the smallest unit worth tracking includes most official documents

A1S6

E3

C4

D5

Payroll v. 0.3.4.2

Payrollv. 0.4.1.0

Payroll v. 0.3.4.3

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.




A1S6

E3

C4

D5

A1S7

E3

C4

D5

Payroll v. 0.3.4.2

Payrollv. 0.4.1.0

Payroll v. 0.3.4.3


Module updated




A1S6

E3

C4

D5

A1S7

E3

C4

D5

Payroll v. 0.3.4.2

A1

D5

Payrollv. 0.4.1.0

S7C4

E3F1

Payroll v. 0.3.4.3


Module added


Configuration Management Requirements Locking - to prevent more than one person

working on a CI at one time Check out - authorization Check-in procedure

Authorization

May inforce testing

Historical record of prior groupings of consistent CI’s

For a list of CM tools:

http://dmoz.org/Computers/Software/Configuration_Management/Tools/

Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.


System Families

Workstationversion

Unixversion

DECversion

Initialsystem

Mainframeversion

VMSversion

PCversion

Sunversion


CM Standards CM should always be based on a set of standards

which are applied within an organisation Standards should define how items are identified, how

changes are controlled and how new versions are managed

Standards may be based on external CM standards (e.g. IEEE standard for CM)

Existing standards are based on a waterfall process model - new standards are needed for evolutionary development

For further info see http://www.rspa.com/spi/SCM.html


IEEE 828-1990 SCMP Table of Contents 3.2 Configuration control

3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or dis-

approving changes 3.2.4 Implementing

changes 3.3 Configuration status accounting 3.4 Configuration audits & reviews 3.5 Interface control 3.6 Subcontractor / vendor control4. SCM schedules5. SCM resources6. SCM plan maintenance

1. Introduction2. SCM management 2.1 Organization 2.2 SCM responsibilities 2.3 Applicable policies, directives & procedures3. SCM activities 3.1 Configuration identification 3.1.1 Identifying configuration items 3.1.2 Naming configuration items 3.1.3 Acquiring configuration itemsAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.


Plan Configuration Management

1. Roughly sketch out your SCMPDetermine procedures for making changes

Omit tool references unless already identified one

See the case study for an example

2. Specify what you need from a CM toolFor class use, maybe only locking and backup

3. Evaluate affordable tools against your needs and budgetCommercial tools are in wide use (here is a list)

For class use, try free document storage web sites; try simple method of checking out e.g. renaming

5. Finalize your SCMP



Software systems are subject to continual change requests From users From developers From market forces

Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost-effective way

Change Management


Request change by completing a change request form Analyze change request if change is valid then Assess how change might be implemented Assess change cost Submit request to change control board if change is accepted then repeat make changes to software submit changed software for quality approval until software quality is adequate create new system version else reject change request else reject change request

The Change Management Process


CRF form layout is part of the CM planning process Records from the requestor:

change requirement (description) requestor’s name reason for change Urgency

Records from the development team: evaluation of change requirement assessment / impact analysis – technical/opertaional feasibility change cost estimate recommendation

Change Request Form


ChangeRequestForm


Assessment portion of Change Request Form

Assessment Technical impact on design, code, testing, etc Risks associated with change External impact on users and operators

Estimate Effort and resources Costs Schedule


Differs from CM tools like CVS A major problem in change management is

tracking change status Change tracking tools keep track of the status of

each change request and automatically ensure that change requests are sent to the right people at the right time.

Integrated with E-mail systems allowing electronic change request distribution

Change Tracking Tools


Changes should be reviewed by an external group who decide whether or not they are cost-effective from a strategic and organizational viewpoint rather than a technical viewpoint

Should be independent of project responsible for system. The group is sometimes called a change control board

May include representatives from client and contractor staff

Change Control Board


Record of changes applied to a document or code component

Should record, in outline, the change made, the rationale for the change, who made the change and when it was implemented

May be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically

Derivation History


Component Header Information


Change Request Form - P1

Project: Registration System Number: 0023

Change requester: DLS Date: 3/28/2005

Description: We would like the system to be played by more than one user at a time over a network.

Change priority: high


Change Request Form - P2

Project: Registration System Number: 0023

Change Assessment:

Analyst: Analysis Date: Technical impact on design, components, code, testing,

etc Risks associated with change External impact on users and operators Effect on resources Effect on costs Effect on schedule


ONE WAY … Change Request Form - P2Project: Registration System Number: 0023Change Assessment:Analyst: Analysis Date:

Technical impact on design, components, code, testing, etc Network centric change in architecture from single system arch Player against player Multi-tasking (threaded) code for concurrent execution of player paths

Risks associated with change Delay in response time of game Currently lack human resources to affect change (can we get them) Server crash means everyone is down Potential for players cheating

External impact on users and operators Will now need a network Will need an administration person Game is potentially more complex due to player-player interactions


ONE WAY … Change Request Form - P2Project: Registration System Number: 0023Change Assessment:Analyst: Analysis Date:

Effect on develop resources Human

A developer with network computing expertise Physical

A server (for at least testing) A system for simulating multiple users A DBMS will be needed (for the game and for financial account) Network hardware / connection Addition infrastructure for added human and physical resources

Effect on costs Hardware = $5000 Human = $60,000*1.30 / 220 * 10 mandays = $3500 Training/Travel = $2500 Infrastructure = $2000 Project management overhead ~ 10% of $13,000 = $1300

Effect on schedule Approximately 1 month

adapted from software engineering, 6th edition. chapter 29, by ian sommerville slide 1 configuration...

Documents

software engineering

ian sommerville slide

configuration control

plan configuration management

configuration identification

scm management

configuration items

a1 d5 payroll