Software Configuration Management SCM

1
Software Configuration Management SCM

• 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

2
Software Configuration Management activities

• Identify changes
• Control change
• Ensure change are being properly implemented
• Report changes to others who may have an interest

3
Software Configuration Management (SCM)

• is a "set of activities designed to control
  change by
• identifying the work products that are likely to
  change,
• establishing relationships among them,
• defining mechanisms for managing different
  versions of these work products,
• controlling the changes imposed, and
• auditing and reporting on the changes made.
• In other words, SCM is a methodology to control
  and manage a software development project.

Roger Pressman, in his book, Software
Engineering A Practitioner's Approach
4
SCM concerns itself with answering the question

• somebody did something, how can one reproduce it?
  
• Most often the issue involves not reproducing
  "it" identically, but with controlled,
  incremental changes.
• Answering the question will thus become a matter
  of comparing different results and of analyzing
  their differences.
• Traditional CM typically focused on controlled
  creation of relatively simple products.
• Nowadays, SCMers face the challenge of dealing
  with relatively minor increments under their own
  control, in the context of a complex given
  system.

5
History of software configuration management

• early 60's or even late 50's IBM UPDATE
• late 60's early 70's, Professor Leon Pressor at
  University of California Santa Barbara did a
  thesis on change and configuration control. This
  concept was a response to a contract he was
  working on with a defense contractor who made
  aircraft engines for the Navy.
• early 70's make
• by 1970 CDC update was an advanced product
• circa 1972 Bell labs paper describing the
  original diff algorithm
• 1972, with an IEEE paper in 1975 source code
  control system, SCCS, (Marc Rochkind) Bell labs.
  Originally programmed in SNOBOL for OS/360
  subsequently rewritten in C for UNIX (used diff
  for comparing files).
• 197x Pansophic's PANVALET was an early source
  code control system for the mainframe market.
  They were based in Lisle, Illinois
• 1975 Pr Pressor's work eventually grew into a
  commercially available product called Change and
  Configuration Control (CCC) which was sold by the
  SoftTool corporation.
• Revision Control System (RCS, Walter Tichy)
• early 80s patch (around 1988, Larry Wall)
• 1984 Aide-de-Camp (ADC, later TrueChange around
  1990, Richard Harter)
• Concurrent Version System (CVS)
• early 2000s distributed revision control systems
  like BitKeeper and GNU arch become viable

6
The goals of SCM are generally

• Configuration Identification -- What code are we
  working with?
• Configuration Control -- Controlling the release
  of a product and its changes.
• Status Accounting -- Recording and reporting the
  status of components.
• Review -- Ensuring completeness and consistency
  among components.
• Build Management -- Managing the process and
  tools used for builds.
• Process Management -- Ensuring adherence to the
  organizations development process.
• Environment Management -- Managing the software
  and hardware that host our system.
• Teamwork -- Facilitate team interactions related
  to the process.

7
Maintenance / Configuration Management

• Maintenance is a set of software engineering
  activities That occur after software has been
  delivered to the customer and until it is taken
  out of operation

• Configuration Management is a set of tracking and
  control activities That begin when a software
  project begins and terminate only when the
  software is taken out of operation

8
Why Configuration Management

• Why configuration management? - try to describe 5
  situations we try to avoid - what are the
  pittfalls?
• Try to describe a model - process needed to avoid
  the pittfalls mentioned before
• Who should have the responsibility for CM?

9
The First Law
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.
Bersoff, et al, 1980
10
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
other documents
user requirements
software models
Project
Plan
data
Test
code
11
The Software Configuration - SCM
programs
documents
The pieces
data
12
Change SCM
Software Engineering
SCM
identification
tools
version control
methods
change control
procedures
auditing
a TQM foundation
reporting
construction
13
Change Control
STOP
14
Change Control ProcessI
need for change is recognized
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
change control processII
15
Change Control Process-II
assign people
check-out
make the change
review/audit the change
establish a baseline for testing
change control processIII
16
Change Control Process-III
perform SQA and testing activities
check-in the changed
inclusion in next release?
rebuild appropriate version
review/audit the change
include all changes in release
17
Auditing
Change Requests
SQA Plan
SCM Audit
18
Status Accounting
Change Reports
Change Requests
Status Accounting
Reporting
19
Do you recognize the problem ?

• An error you once have corrected comes back again
  !
• You make an improvement for a good customer. Just
  after installation of a new version the customer
  claims that the improvement has disappeared.
• A customer calls but you cant figure out which
  program the customer has installed !
• A strange error makes you investigate in the code
  for days until you finds out that the code you
  investigate is not the code corresponding to the
  error !
• No one can figure out if a change which have been
  decieded to implement is implemented or not !

20
Request for discussion
Do you know any of the problems ? What are the
worst examples you can think of ?
21
Three core areas
Identification of configurations- components
Configurations- status and archive
Configurations- control
22
Relations between key areas
Identification of configurations- components
Configurations- status and archive
Product- descriptions
Baselines
Components to be controlled
Accepted changes
Changes
Configurations- control
Control-procedures
23
Identification of components 1

• What does the (software-) product consists of ?
• What is the smallest entity of the product you
  change?
• Which documentation are needed for the product,
  first at the development phase afterwards when
  delivered to customer ?
• What is the smallest entity of the documentation
  you change ?

24
Identification af components 2

• Each component (document or code) must have an
  identification which
• Must be unique
• Should signal what the component is a part of
• Should signal when the component is created

25
Identification of components 3

• componenter is part of a hierarki i.e..
• Releases / Baselines
• 1.0, 2.0, 3.0 ...
• Version / updates
• 1.1, 1.2, 1.3, 1.4
• fixes /
• 1.1.1, 1.1.a, 1.11

26
Request for discussion in your projectgroup
Which components do you want in your project ?
Where are you going to keep it ? Are there a
difference between programs and documents ?
27
Baseline

• A specification or a product That has been
  formally reviewed and agreed upon, That
  thereafter serves as the basis for further
  development, and That can only be changed through
  formal change control procedures

28
Typical Baselines

• A baseline is at point which can be referred
  which can be defined after each phase in the
  development of a product, i.e..,
• After the requirement specification gt Functional
  Baseline
• After program design gt Allocated Baseline
• After module design gt Design Baseline
• After coding and test gt Product Baseline
• After integration gt Operational Baseline

29
Function Baseline

• Ex. of content of a Functional Baseline (FB)
• Pre-analysis Report
• Risk analysis report
• Product requirement specification
• Software requirement specification
• Acceptance test specification
• Usermanual - first version

30
Product Baseline

• Ex. of content of a Product Baseline (PB)
• Print of code (source code)
• Files containing source code
• Files containing object code
• Executable code
• Module test - reports

31
For discussion
Which phases are there in your development
process? Which baselines would be appropriate?
32
Configuration control
Components to be controled
Configuration- control
Accepted changes
Change requests
Control procedures
33
Changes comes from two sources

• Error reports
• Need for improvements
• Independent of the source the change request must
  be evaluated, a decision and priority,
  implementation, tested and accepted.

34
Responsibility for changes

• Important that the responsibility for evaluation
  and decision are clear
• Change Control Board or a group . Has the
  responsibility
• From the group meetings notes of accepted changes
  (SCN Software Change Notice)

35
Change management

• Establish a change list/log
• Fill in a change request consequences
• Accept, reject or put it on as a request
• Project group
• Steering committee
• Update the change document
• Re plan and implement changes in
• Project documentation and software

Change request
36
Request for discussion
How are you registrating errors and defects from
i.e. fra reviews? Skal I have en
formaliseret måde at afhjælpe fejl ?
37
Configuration status and archive
Configuration- status and archive
Baselines
Accepted changes
38
Software-archivealso named Software-library

• Place where the official version of all documents
  and all source codes are.
• A formal procedure to put new or corrected things
  in the archive (tinglysning), based on
  decisions from the configuration control
• Delivering out work copies registration of who
  has/uses what.

39
Archive other tasks

• Make the whole product ready for delivery Only
  the archive must give out material to customers.
• Re-use Gives overviews. Register different
  variations
• Documentation center Keep all letters, notes
  etc. . Gives the history.

40
Request for discussion
Who archives in the project ? What and where are
material archieved ? How are you securing that
components can be reused next semester? Who
makes the product ready for delivery to the
customer (i.e. teacher and external censor in
November) ?
41
Literature

• Software Engineering a practitioners approach,
  chapter 27
• http//www.dwheeler.com/essays/scm.html
• http//www.software-pointers.com/en-configuration-
  tools.html
• http//en.wikipedia.org/wiki/Software_configuratio
  n_management