Software configuration management (SCM)
1
Software configuration management (SCM)
Software configuration management is a set of tracking and
control activities that begin when a software engineering project
begins and terminate only when the software is taken out of
operation
is concerned with the policies, processes, and tools for
managing changing software systems
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
– auditing and reporting on the changes made.
2
Sources of Change
New business or market conditions
– dictate changes to SW requirements or business rules
New customer needs
– demand modification of data, functionality, or services
Business reorganization
– causes changes in project priorities or software engineering team
structure
Budgetary or scheduling constraints
– cause system to be redefined
3
Software Configuration Management Tasks
Identification
– tracking multiple versions to enable efficient changes
Version control
– control changes before and after release to customer
Change control
– authority to approve and prioritize changes
Configuration auditing
– ensure changes made properly
Reporting
– tell others about changes made
4
Software Configuration Items
Computer programs
– both source and executable forms
Documentation
– describing the computer programs (targeted at both technical
practitioners users
Data
– contained within the program or external to it
5
Baselines
A baseline is a software configuration management concept
that helps us to control change without seriously impeding
justifiable change
a milestone in the development of software that is marked by
the delivery of one or more software configuration items and
the approval of these SCIs that is obtained through a formal
technical review
6
Identification
To control and manage configuration items
– each must be named
– should be managed using an object-oriented
approach
Basic objects
– created by software engineers during analysis,
design, coding, or testing
Aggregate objects
– collections of basic objects and other aggregate
objects7
Version Control
Combines procedures and tools to manage the
different versions of configuration objects created
during the software process
Represented in evolution graph
– An entity is composed of objects at the same revision level
– A variant is a different set of objects at the same revision level
and coexists with other variants
– A new version is defined when major changes have been
made to one or more objects
8
9
Change Control
Change request
– submitted and evaluated to assess technical merit and impact
on the other configuration objects and budget
Change report
– contains the results of the evaluation
Change control authority (CCA)
– makes the final decision on the status and priority of the
change based on the change report
Engineering change order (ECO)
– generated for each change approved (describes change, lists
the constraints, and criteria for review and audit)10
Change Control
Object to be changed is checked-out of the project database
subject to access control parameters for the object
Modified object is subjected to appropriate SQA and testing
procedures
Modified object is checked-in to the project database and
version control mechanisms are used to create the next version
of the software
Synchronization control
– used to ensure that parallel changes made by different
people don’t overwrite one another
11
12
CONFIGURATION AUDIT
How can we ensure that the change has been properly
implemented?
Two approaches
– formal technical reviews and the software configuration audit
formal technical review
– focuses on the technical correctness of the configuration object that
has been modified
software configuration audit
– complements the formal technical review by assessing a
configuration object for characteristics that are generally not
considered during review
13
Software Configuration Audit Questions
Has the change specified by the ECO been made without
modifications?
Has an FTR been conducted to assess technical correctness?
Was the software process followed and software engineering
standards applied?
Do the attributes of the configuration object reflect the change?
Have the SCM standards for recording and reporting the change
been followed?
Were all related SCI's properly updated?
14
Reporting
Configuration status reporting (sometimes called status
accounting) is an SCM task that answers the following
questions:
– What happened?
– Who did it?
– When did it happen?
– What else will be affected?
Each time a configuration audit is conducted, the results are
reported as part of the CSR task.
Output from CSR may be placed in an on-line database, so that
software developers or maintainers can access change
information by keyword category.
plays a vital role in the success of a large software development
project15
ClearQuest
This tool is a change request management application that allows a
developer to track and monitor the change requests for a
configuration item
ClearQuest maintains its own database which stores all the change
requests in the form of records.
There are various categories of changes that can be done on a
product. These changes can be due to addition of new features,
detection of faults, activities etc.
16
Managing Configurations in Open Source Projects
Version management
– write access to the CVS repository is granted hence several hundred
developers can add new versions to it
– Some make exception, as they use no tool at all for version control
such as
Linux
– Contributions can only be applied to the repository by the
moderators and there is no version history, as they violate the
version control principle of immutability.
– When a new release is created, the latest is duplicated into a
new release directory to conserve it even if development
continues,
17
Configuration Selection
Almost always the latest version of all files is used to build a
configuration
Since only one release is maintained (the latest) there is no
need to return to other configurations.
Only in the case where you want to install an older release
are they retrieved.
In the cases where one stable and one development release
are maintained concurrently they are run as two separate
projects
18
Change management
In traditional projects only approved change proposals are
assigned to developers.
In OSS the evaluation of change proposals is not explicit,
Anyone can propose a change and most often changes are
not even proposed before a change is submitted directly.
Change proposals might be prioritized implicitly or explicitly,
but an OSS project cannot assign tasks to developers –
everyone works on what has been chosen.
Patches are reviewed in multiple steps before testing,
Contributions that are found ill-designed or have not so
sound ideas are rejected
19
Change Process for OSS
20
Release Management
Different from The traditional
No fixed release dates and labelling and release is mostly
arbitrary
When an internal release is getting nearer, the development
branch enters a freeze stage.
– Initially, the soft freeze stage means that new features, which
break compatibility are discouraged, but not forbidden.
– They then move to a hard freeze, which in practice means
that any contribution that will change an interface is
forbidden. Only bug fixes are allowed.
21
Reading
– Pressman Software engineering: a practitioner’s approach Chapter 9
– Somerville Software engineering 9th edition chapter 25
Thank you
22
Top Related