Lect 4-SE II

8/3/2019 Lect 4-SE II

1/37

1

Software Configuration Management


8/3/2019 Lect 4-SE II

2/37

2


First Law of Software Engineering

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

8/3/2019 Lect 4-SE II

3/37

3


What are these changes?

SWE 418 (062) C fi ti M t 3

data

otherdocuments

codeTest

Project

Plan

changes intechnical requirements

changes inbusiness requirements

changes in

user requirements

software models

8/3/2019 Lect 4-SE II

4/37

4


The Software Configuration

SWE 418 (062) C fi ti M t 4

programs documents

dataThe pieces

8/3/2019 Lect 4-SE II

5/37

5


Software development process:

The larger the software, the harder to maintain it.

When a change required:

Who will do it?

How will s/he do it?

How will the change incorporated in the whole software?

How to guarantee change will not inject any othertroubles?

After a change made:

When it is made?

Who made it, why s/he made it?

8/3/2019 Lect 4-SE II

6/37

6


Formal definition of SCM:

Software Configuration Management is a set of engineering

procedures for tracking and documenting software

throughout its life cycle, to ensure that all changes are

recorded and current state of the software is known and

reproducible.

8/3/2019 Lect 4-SE II

7/37

7


Configuration Management

Configuration management is concerned with managingevolving software systems:

System change is a team activity;

CM aims to control the costs and effort involved in making

changes to a system.

8/3/2019 Lect 4-SE II

8/37

8


Configuration Management (cont..)

Involves the development and application of procedures andstandards to manage an evolving software product.

Ensures that the products and their descriptions are correctand complete

Configuration management specialists identify and documentconfiguration requirements, control changes, record andreport changes, and audit the products to verify conformanceto requirements

CM may be seen as part of a more general qualitymanagement process.

When released to CM, software systems are sometimescalled baselinesas they are a starting point for furtherdevelopment.

8/3/2019 Lect 4-SE II

9/37

9


Problems without SCM

Without SCM, we can face following problems:

Simultaneous Update

Redundant work for maintenance

Shared code & work products

No Control on Versions

8/3/2019 Lect 4-SE II

10/37

10


Baselines

A specification or a product, which is formally reviewed and

agreed on, and which can only be changed through formal

change procedures

Before an item becomes a baseline, changes can be made

quickly and informally.

Baseline is a kind of a milestone in software development

Baseline typically creates new versions in SCIs.

8/3/2019 Lect 4-SE II

11/37

11


Examples:

Baseline A: All the API have completely been defined;the bodies of the methods are empty.

Baseline B: All data access methods are implementedand tested.

Baseline C: TheGUI is implemented.

8/3/2019 Lect 4-SE II

12/37

12


Goals of SCM

The goals of SCM are generally:

Configuration identification - What code are we working with?Or What do we have, and how is it structured?

Configuration control - Controlling the release of a product

and its changes.

Status accounting - Recording and reporting the status ofcomponents.

Review - Ensuring completeness and consistency among

components.

8/3/2019 Lect 4-SE II

13/37

13


Goals of SCM

Build management - Managing the process and tools usedfor builds.

Process management - Ensuring adherence to theorganization's development process.

Environment management - Managing the software andhardware that host our system.

Teamwork - Facilitate team interactions related to theprocess.

Defect tracking - Making sure every defect has traceabilityback to the source
http://en.wikipedia.org/wiki/Build_managementhttp://en.wikipedia.org/wiki/Process_managementhttp://en.wikipedia.org/wiki/Teamworkhttp://en.wikipedia.org/wiki/Teamworkhttp://en.wikipedia.org/wiki/Process_managementhttp://en.wikipedia.org/wiki/Build_management

8/3/2019 Lect 4-SE II

14/37

14


Formal Configuration Management

Activities1. Configuration Identification

What do we have, and how is it structured?

2. Configuration Control

Another way of saying change control3. Configuration Status Accounting

Documents on configuration, versions, change history

4. Configuration Auditing

Review of documents and systems

Formal Configuration Management Activities

8/3/2019 Lect 4-SE II

15/37

15


1. Configuration Identification Identify and uniquely name the components (configuration

items or CI) of your system

Give version numbers to each individual CI

Establish configuration baselines (e.g. freezes) by

identifying the structure of how CIs interconnect to form yoursystem

Making revisions to your CIs or structure causes revisions tothe configuration baseline

This creates the basis for change traceability

Note: The term frozen means that the item can only bechanged by creating a new version.

Formal Configuration Management Activities

8/3/2019 Lect 4-SE II

16/37

16


2. Configuration Control A process for managing changes to an established system

baseline

Assign change roles and responsibilities

Process change requests Specify required change activities

Track change history and approvals

Establish new system baselines

Configuration Control is another way of saying Change

Control

8/3/2019 Lect 4-SE II

17/37

17


3. Configuration Status Accounting Simply, a paper trail (or electronic trail) of documentation

showing the history of configuration items and changes tothem

Should include dates, component identifications, versions,

baseline descriptions, change details, information about thepeople involved

8/3/2019 Lect 4-SE II

18/37

18


4. Configuration Auditing Also known as Configuration Evaluation

Just what it sounds like: an audit process that evaluates theeffectiveness of the configuration management system

Reviews the trail generated by Status Accounting

Verifies that the systems current configuration matches whatthe CM system claims

8/3/2019 Lect 4-SE II

19/37

19


Configuration management planning

All products of the software process may have to be managed: Specifications;

Designs;

Programs;

Test data; User manuals.

Thousands of separate documents may be generated for a large,complex software system.

SWE 418 (062) Configuration Management 19

8/3/2019 Lect 4-SE II

20/37

20


The CM plan

Defines the types of documents to be managed and a

document naming scheme. Defines who takes responsibility for the CM procedures and

creation of baselines.

Defines policies for change control and versionmanagement.

Defines the CM records which must be maintained.

Describes the tools which should be used to assist the CMprocess and any limitations on their use.

Defines the process of tool use.

Defines the CM database used to record configurationinformation.

May include information such as the CM of externalsoftware, process auditing, etc.


8/3/2019 Lect 4-SE II

21/37

21


Change management

Software systems are subject to continual change requests:

From users;

From developers;

From market forces.

Change management is concerned with keeping track ofthese changes and ensuring that they are implemented inthe most cost-effective way.


8/3/2019 Lect 4-SE II

22/37

22


What is Change Control?As previously mentioned, this is also known as the

Configuration Control activity of CM

Change control is the process used to request, review, plan,approve, and implement changes to a system

When its properly implemented, change control assures thatunplanned changes dont happen, and that planned changesare well-managed

8/3/2019 Lect 4-SE II

23/37

23


What is Change Control? (cont) Larger projects have a formal Change Control Board whose

responsibility it is to review and approve or disapprove

change. It is the CCB responsibility to provide the

mechanism to maintain orderly change processes.

8/3/2019 Lect 4-SE II

24/37

24


Change Controls Board (CCB)

ChangeProposals

Document

Change

Review byCCB

Implement

Verify

Accept

Reject

8/3/2019 Lect 4-SE II

25/37

25


Change Control Process

Evaluate the change request

Assign individuals to configuration objects

check-out configuration objects

make the change

review (audit) the change

check-in the changed configuration items

establish baseline for testing

8/3/2019 Lect 4-SE II

26/37

26


promote changes for inclusion in next release

rebuild, review

include in new version

distribute the new version

Change Control Process (cont)

8/3/2019 Lect 4-SE II

27/37

27


Change Control ProcessI

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

need for change is recognized

change control processII

8/3/2019 Lect 4-SE II

28/37

28


Change Control Process-II

assign people to SCIs

check-out SCIs

make the change

review/audit the change

establish a baseline for testing

change control processIII

8/3/2019 Lect 4-SE II

29/37

29


Change Control Process-III

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

8/3/2019 Lect 4-SE II

30/37

30


Change request form

The definition of a change request form is part of the CMplanning process.

This form records the change proposed, requestor ofchange, the reason why change was suggested and the

urgency of change (from requestor of the change). It also records change evaluation, impact analysis, change

cost and recommendations (System maintenance staff).


8/3/2019 Lect 4-SE II

31/37

31


Terminology:

Configuration

Configuration Item

Versions

Variants

Releases

Version control

8/3/2019 Lect 4-SE II

32/37

32


Configuration

To setup or change something in such away that it is readyfor operation for a particular purpose.

Or

The functional and physical characteristics of hardware or

software as set forth (express) in technical documentation orachieved in a product.

8/3/2019 Lect 4-SE II

33/37

33


Configuration Item

An aggregation of hardware or software or both that is designated

for configuration management and is a single entity inconfiguration management process

Software configuration items are not only program code segments

but all type of documents according to development, e.g

all type of code files

analysis or design documents

user or developer manuals

system configurations (e.g. version of compiler used)

In some systems, not only software but also hardware configurationitems (CPUs, bus speed frequencies) exist!

8/3/2019 Lect 4-SE II

34/37

34


Configuration Management

Configuration management refers to the process of defining

Configuration Items within a system and recording and

reporting on the status of the CIs and any requests for

change ,then verifying the correctness of a CI.

8/3/2019 Lect 4-SE II

35/37

35


Versions/variants/releases

Version: an instance of a system which is functionallydistinct in some way from other system instances.

Variant: an instance of a system which is functionallyidentical but non-functionally distinct from other instances ofa system.

Release: an instance of a system which is distributed tousers outside of the development team.


8/3/2019 Lect 4-SE II

36/37

36


Version Control

Version control works to help manage the configurationitems needed for particular versions during thedevelopment process.

8/3/2019 Lect 4-SE II

37/37

37


Version control Procedures and tools to manage different versions of

configuration objects

Versions may not always be created in sequential order,e.g. you create 1.0 -> 1.1 -> 1.2 -> 2.0 and then you needto create 1.3 for some customers who can not run 2.0 butneed some changes or improvements.

With big software, you may e.g have 4.0 as the officialcurrent version. You work on 5.0 to release it as the nextofficial version, butyou have already started to create 6.0,

as it takes so long to get it ready.