12/06/2005 1

Software Configuration Management

• Configuration management (CM) is the process that controls the changes made to a system and manages the different versions of the evolving software product.

• CM consists of a set of tracking and control activities that begin when a software engineering project begins and terminates when the software retires.

12/06/2005 2

Configuration management

• Configuration management planning – Configuration item identification– The configuration database

• Change management

• Version and release management

• System building

12/06/2005 3

Baselines

IEEE std. NO 610.12-1990:

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

12/06/2005 4

Version and release management

• Version identification1. Version numbering2. Attribute-based identification3. Change-oriented identification

Release Management– Release decision-making– Release creation– Release documentation

12/06/2005 5

The Change Control Process

1. Need for change is recognized

2. Change request from user

3. Developer evaluations

4. Change report is generated

5. Change control authority decides 5.1 Change request is denied ->User is

informed

5.2 Request is queued for action

12/06/2005 6

1. Assign individuals to configuration items2. Check out configuration items3. Make the change4. Review the change5. Check in the configuration items that have been changed6. Established a baseline for testing7. Perform quality assurance and testing activities8. Promote changes for inclusion in next release9. Rebuild appropriate version of software10. Review the change to all configuration items11. Include changes in new version12. Distribute the new version

12/06/2005 7

Software Change

Requirements analysis System and

software design Implementationand unit testing Integration and

system testing Operation and maintenance

Requirement Change

Design Change

Code Change

Requirement Change•User requests•Organizational change•Business change•New requirement•Environment change•Functionality change

Design Change•Requirement change•Design error correction•Design tradeoff•Feature enhancement

Code Change•Requirement change•Design change•Error fix•Algorithm improvement•Data structure change

12/06/2005 8

Impacts of Software Change• Vertical Impact

– Identify software artifacts associated with an earlier phase change

• Horizontal Impact– Identify software entities affected by changes

at the same phase

12/06/2005 9

Change Impact Analysis• Software Change Impact Analysis

– Identifies the potential consequences• What areas might be affected and what needs to be modified

– Estimates the efforts required• The number of entities need to be modified• The complexity of the entities

– Aids in change request decisions• Degree of effects• Time to complete change• Cost of change

• Ripple effect analysis• Determines affected portions of a system after a change • An iterative process

12/06/2005 10

Multiple Views of Impact Analysis

• Managers – Cost of change implementation

• Team leaders – Affected subsystems and teams

• Programmers – Affected code sections

• Maintainers– Affected test cases

12/06/2005 11

Existing Techniques• Traceability analysis (Vertical Impact)

– Dependency among software lifecycle artifacts– Requirements– Design– Source code– Test cases

• Dependency analysis (Horizontal Impact)– Dependency among program entities

– Variables– Logic– Modules

12/06/2005 12

Traceability Analysis Approaches• Sodos (Software Document Support)

– Documentation management system• Manually enter document content• Manually enter relationships among software lifecycle

artifacts

• Alicia (Automated Life Cycle Analysis System)– Traceability-based impact analysis system

• Describes change, lets user select traceability starting point

• Marks impacted object in project database• Visually traverse and browse project database

12/06/2005 13

Dependency Analysis Approaches• Dependency Relationships

– Data dependency• Dependency relationships among program

statements that define or use data• Data-flow analysis

– Control dependency• Dependency relationships among program

statements that control program execution• Control-flow analysis

12/06/2005 14

Dependency Analysis Approaches

• Impact Determination Techniques– Transitive closure

• Input – A graph of objects and relationships

• Determine all objects reachable from any object to any other object through paths of length 0 or more

Graph G Graph G*

(Transitive Closure of G)Module A

Module B Module C

Module D Module A

Module B Module C

Module D

12/06/2005 15

Dependency Analysis Approaches

• Impact Determination Techniques (cont’d)– Inferencing

• Use rules to characterize relationships among objects• Consists of

– A database of facts– Inferencing rules for new facts– Search management mechanism

• For example,– Module(A), Module(B), Module(C), Module(D)– Calls(A,B), Calls(B,C), Calls(C,D), Calls(D, A)– Inferencing rule

» Calls(X,Y) and Calls(Y,Z) -> Indirectly_Calls(X,Z)– Calls(A,B) and Calls(B,C) -> Indirectly_Calls(A,C)

12/06/2005 16

Dependency Analysis Approaches (cont’d)

• Impact Determination Techniques (cont’d)– Program slicing

• Utilize control-flow and data-flow information• Slicing criteria – point of interest• Program slice

– An executable subset of original program affected by the change

x = 1; (change)k = 3;p = x + y;z = y – 2;if(p==0) r++;

p = x + y;if(p==0) r++;

12/06/2005

Program Slicing

• The backward slice w.r.t variable v at program point p The program subset that may influence the value ofvariable v at point p.

• The forward slice w.r.t variable v at program point pThe program subset that may be influenced bythe value of variable v at point p.

12/06/2005

int main() {int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

}

Backward Slice

Backward slice with respect to statement “printf(“%d\n”,i)”

12/06/2005

int main() {int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

}

Backward slice with respect to statement “printf(“%d\n”,i)”

Backward Slice

12/06/2005

Forward Slice

int main() {int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

}

Forward slice with respect to statement “sum = 0”

12/06/2005

int main() {int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

}

Forward slice with respect to statement “sum = 0”

Forward Slice

12/06/2005

What Are Slices Useful For?• Understanding Programs– What is affected by what?

• Restructuring Programs– Isolation of separate “computational threads”

• Program Specialization and Reuse– Slices = specialized programs– Only reuse needed slices

• Program Differencing– Compare slices to identify changes

• Testing– What new test cases would improve coverage?– What regression tests must be rerun after a change?

12/06/2005

How are Slices Computed?

• Reachability in a Dependence Graph

– Program Dependence Graph (PDG)• Dependences within one procedure

• Intraprocedural slicing is reachability in one PDG

– System Dependence Graph (SDG)• Dependences within entire system

• Interprocedural slicing is reachability in the SDG

12/06/2005

Backward Sliceint main() {

int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

} Enter

sum = 0 i = 1 while(i < 11) printf(sum) printf(i)

sum = sum + i i = i + i

T

TT T

TTT

T

12/06/2005

Backward Sliceint main() {

int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

} Enter

sum = 0 i = 1 while(i < 11) printf(sum) printf(i)

sum = sum + i i = i + i

T

TT T

TTT

T

12/06/2005

Backward Sliceint main() {

int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

} Enter

sum = 0 i = 1 while(i < 11) printf(sum) printf(i)

sum = sum + i i = i + i

T

TT T

TTT

T

12/06/2005

Backward Sliceint main() {

int sum = 0;int i = 1;while (i < 11) {

sum = sum + i;i = i + 1;

}printf(“%d\n”,sum);printf(“%d\n”,i);

} Enter

sum = 0 i = 1 while(i < 11) printf(sum) printf(i)

sum = sum + i i = i + i

TT

TT T

TTT

12/06/2005

Slice Extractionint main() {

int i = 1;while (i < 11) {

i = i + 1;}

printf(“%d\n”,i);} Enter

i = 1 while(i < 11) printf(i)

i = i + iT

TT

TT

12/06/2005

Interprocedural Slice

int main() {int sum = 0;int i = 1;while (i < 11) {

sum = add(sum,i);i = add(i,1);

}printf(“%d\n”,sum);printf(“%d\n”,i);

}

int add(int x, int y) {return x + y;

}

Backward slice with respect to statement “printf(“%d\n”,i)”

12/06/2005

Interprocedural Slice

int main() {int sum = 0;int i = 1;while (i < 11) {

sum = add(sum,i);i = add(i,1);

}printf(“%d\n”,sum);printf(“%d\n”,i);

}

int add(int x, int y) {return x + y;

}

Backward slice with respect to statement “printf(“%d\n”,i)”

12/06/2005 31

Limitations of existing impact analysis approaches

– Code based impact analysis prior to change– Ripple effect analysis performed on modified code for

each propagated change– Expensive to construct data-flow graphs after each modification

– Software development across teams or organizations– No centralized source code repository

– Difficult to perform system-wide control-flow and/or data-flow analyses

– Object-Oriented (OO) systems– No efficient data-flow algorithms available

– Component-based development with COTS (Commercial off-the shelf) components

– No source code available for customer

– Frequent component upgrades/updates

12/06/2005 32

Software Maintenance

• The process of changing a system after it has been delivered and is in use.– Corrective maintenance

• To correct residual faults– Adaptive maintenance

• Responses to changes in the environment in which the product operates

– The product is ported to a new compiler, operating system, and/or hardware

– Perfective maintenance• Client requests changes to improve product effectiveness

– Add additional functionality– Make product run faster– Improve maintainability

12/06/2005 33

Corrective Maintenance

• Suppose that the maintenance programmer has located the fault

• Problem:– How to fix it without introducing a regression fault

12/06/2005 34

Corrective Maintenance (contd)

• How to minimize regression faults– Consult the detailed documentation for the product as a

whole– Consult the detailed documentation for each individual

module

• What usually happens– There is no documentation at all, or – The documentation is incomplete, or – The documentation is faulty

12/06/2005 35

Corrective Maintenance (contd)

• The programmer must deduce from the source code itself all the information needed to avoid introducing a regression fault

• The programmer now changes the source code

12/06/2005 36

The Programmer Now Must

• Test that the modification works correctly– Using specially constructed test cases

• Check for regression faults – Using stored test data

• Add the specially constructed test cases to the stored test data for future regression testing

• Document all changes

12/06/2005 37

Corrective Maintenance (contd)

• Major skills are required for corrective maintenance– Superb diagnostic skills– Superb testing skills– Superb documentation skills

12/06/2005 38

Adaptive and Perfective Maintenance

• The maintenance programmer must go through the– Requirements – Specifications– Design– Implementation and integration

workflows, using the existing product as a starting point

12/06/2005 39

Adaptive and Perfective Maintenance (contd)

• When programs are developed– Specifications are produced by analysis experts– Designs are produced by design experts– Code is produced by programming experts

• But a maintenance programmer must be expert in all three areas, and also in– Testing, and– Documentation

12/06/2005 40

Maintenance Cost :Technical Factors

• Module Independence

• Programming language

• Programming style

• Program validation

• Documentation

• Configuration Management

12/06/2005 41

Maintenance Cost : Non-technical factors

• Application domain

• Staff stability

• Program age

• External environment

• Hardware stability

12/06/2005 42

Maintenance Cost Estimation

AME = ACT * SDT

• AME: Annual effort required • ACT: Annual Change Traffic: The fraction of software

product's source instructions which undergo change during a year either through addition or modification.

• SDT: Software development time and the units of each are person-months.

12/06/2005 43

Maintainability Measurement

• Number of requests for corrective maintenance

• Average time required for impact analysis

• Average time taken to implement a change request

• Number of outstanding change requests