Configuration and Change Management

1
Configuration and Change Management

• Managing the products of system change

2
Topics covered

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

3
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

4
Configuration Items (CIs)

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

Payroll v. 0.4.1.0
Payroll v. 0.3.4.3
Payroll v. 0.3.4.2
S6
A1
C4
D5
E3
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5
Configuration Items (CIs)

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

Module updated
Payroll v. 0.4.1.0
Payroll v. 0.3.4.3
Payroll v. 0.3.4.2
S7
S6
A1
A1
C4
C4
D5
D5
E3
E3
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
6
Configuration Items (CIs)

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

Module added
Payroll v. 0.4.1.0
Payroll v. 0.3.4.3
Payroll v. 0.3.4.2
S7
S7
S6
A1
A1
A1
C4
C4
C4
D5
D5
D5
E3
E3
E3
F1
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
7
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 CIs
• 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.
8
System Families
9
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.h
  tml

10
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 control 4. SCM schedules 5. SCM
resources 6. SCM plan maintenance
1. Introduction 2. SCM management 2.1
Organization 2.2 SCM responsibilities 2.3
Applicable policies, directives
procedures 3. SCM activities 3.1
Configuration identification
3.1.1 Identifying configu-
ration items 3.1.2 Naming configu-
ration items 3.1.3
Acquiring configu- ration
items
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
11
Plan Configuration Management
One way to ...

• 1. Roughly sketch out your SCMP
• Determine 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 tool
• For class use, maybe only locking and backup
• 3. Evaluate affordable tools against your needs
  and budget
• Commercial 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

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

• 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

13
The Change Management Process
14
The Change Management Process
15
The Change Management Process
16
The Change Management Process
17
Change Request Form

• CRF form layout is part of the CM planning
  process
• Records from the requestor
• change requirement (description)
• requestors name
• reason for change
• Urgency
• Records from the development team
• evaluation of change requirement
• assessment / impact analysis technical/opertaion
  al feasibility
• change cost estimate
• recommendation

18
ChangeRequestForm
19
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

20
Change Tracking Tools

• 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

21
Change Control Board

• 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

22
Derivation History

• 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

23
Component Header Information
24

• 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

25

• 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

26

• ONE WAY Change Request Form - P2
• Project Registration System Number 0023
• Change 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

27

• ONE WAY Change Request Form - P2
• Project Registration System Number 0023
• Change 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,0001.30 / 220 10 mandays 3500
• Training/Travel 2500
• Infrastructure 2000