cse 7315 - sw project management / module 31 - software configuration management principles...

CSE 7315 - SW Project Management / Module 31 - Software Configuration Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey, All Rights Reserved

Slide 1

CSE7315M31August 13, 2006

SMU CSE 7315Planning and Managing a

Software Project

Module 31Software

Configuration Management Principles

Slide # 2August 13, 2006

CSE 7315 - SW Project Management / Module 31 - Software Configuration

Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,

All Rights Reserved

CSE7315M31

Objective of This Module

• To discuss basic principles of software configuration management:

Text, chapters 7, 12




All Rights Reserved

CSE7315M31

What Is Software Configuration Management?

Definition:

Software Configuration Management is the process of

identifying, organizing and managing modifications to

software

Software Configuration Management is the process of

identifying, organizing and managing modifications to

software




All Rights Reserved

CSE7315M31

Purpose ofConfiguration Management

The purpose of configuration management is to maintain integrity of the product by

controlling change to the product

The purpose of configuration management is to maintain integrity of the product by

controlling change to the product




All Rights Reserved

CSE7315M31

• All components that make up or relate to a version of a product– The proper version of each:

What Is The Configuration?

� document� compiler used to develop� development tool� data set used for

simulating� special equipment� operating system

� test code� test data� library� procedur

e� hardware� etc.

� module� component� data file� macro� simulator� specification

If any of the above is wrong, the product lacks integrity and may not work

If any of the above is wrong, the product lacks integrity and may not work




All Rights Reserved

CSE7315M31

What is Integrity?

Having the right parts that all fit together to form a correct product.

ListingUser’s Guide

Main, rel 2.3Sub1, rel 1.7Sub2, rel 3.1...

Object code




All Rights Reserved

CSE7315M31

Why is SW Configuration Management Needed?

• Because software is flexible, changeable, and intangible

• It is too easy to lose integrity of software because of these factors

Unmanaged change is very possibly the largest single cause of failure to deliver

systems on time and within budget.NASA SCM Guidebook, August, 1995

Unmanaged change is very possibly the largest single cause of failure to deliver

systems on time and within budget.NASA SCM Guidebook, August, 1995




All Rights Reserved

CSE7315M31

Examples of Loss of IntegrityPossibleCause(s) Example

6, 7 Performance 2 years ago cannot be duplicated with the current release

2,3 Source code will not compile without errors

2,3 Source code will not link without errors

2,3 Source code will not execute without errors

2,3 Compiled code will not execute with the same results as the released code




All Rights Reserved

CSE7315M31

More Examples of Loss of Integrity

PossibleCause(s)Example 2,3 Compiled code has different object code or

code size from released code 1 A bug that we fixed once before has

reappeared 1,2,5 Code does not match the design

specification 1,5 Design does not match requirements spec.




All Rights Reserved

CSE7315M31

More Examples of Loss of IntegrityPossible

Cause(s)Example

1, 7 A feature that we added and fully tested has suddenly stopped working

2 It worked in the factory but not in the field

1 All records of a particular feature are gone, and the programmer/designer left the company

2,4 You cannot figure out which version of each module is needed to reproduce a problem we found in the field




All Rights Reserved

CSE7315M31

Possible Causes ofIntegrity Problems

Number Cause 1 Simultaneous update.

– When more than one person simultaneously updates the same piece of software

– Care must be taken to avoid one person’s changes overwriting the other’s

– This tends to cause the kinds of problems where “solved” problems reappear




All Rights Reserved

CSE7315M31

Example of Simultaneous Update

• A major update and a quick fix to the same module.

ABC v2.0

ABC v1.1

ABC v1.0

debug

enhance

Does not reflect the fixes in v

1.1




All Rights Reserved

CSE7315M31

More Possible Causes of Integrity Problems

Number Cause

2 Multiple uses of an updated module.

-- Perhaps not all copies were changed

-- Perhaps because not all were known.

3 Multiple users of an updated module

-- Not all notified and perhaps not all are known.

These are examples of the double maintenance problem.

These are examples of the double maintenance problem.




All Rights Reserved

CSE7315M31

Double Maintenance Problem

• When two or more copies of the same software exist• Any change made to one MUST be

applied to all

• Results in symptoms where system behavior varies from one place to another

Application TApplication S

Module M




All Rights Reserved

CSE7315M31

Some Common Issues

• Not everyone knows about all copies of the module– Individuals use unauthorized or

unofficial copies of a module

• Someone changes a module without understanding how that module is being used elsewhere– And does not notify others of the

change




All Rights Reserved

CSE7315M31

Another Multiple Use ProblemChange subroutine from 4 inputs to 3 inputs

CALL SUB(X,Y,Z)

CALL SUB(A,B,C)

CALL SUB(Q,R,S)

CALL SUB(K,L,M,N)

SUBROUTINE SUB(I,J,K)

INTEGER I; REAL J,K

FOR I := 1 TO J DO

IF K < J THEN ...

...

RETURN

END

New Version

Oops! This call was not changed.




All Rights Reserved

CSE7315M31


Number Cause

4 Multiple releases with inadequate information on the content of each

4a Multiple compilers or other tools were used to develop the software, but it is unclear as to which was used for which release.




All Rights Reserved

CSE7315M31


Number Cause

5 Changes to code were not reflected in other development artifacts (design, user guide, etc.)

6 Failure to keep track of versions or to control changes to the software




All Rights Reserved

CSE7315M31


Number Cause

7 Shared data problem:

more than one person depends on the same module to provide functionality to other modules • Can usually be avoided by designing on

the principle of information hiding• Usually results in problems where a part

of the system starts behaving in an unexpected way –e.g it stops compiling all of a sudden

CSE 7315 - SW Project Management / Module 31 - Software Configuration Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey, All Rights Reserved

Slide 20

CSE7315M31August 13, 2006

There are Fundamental Reasons Why These Problems

Happen

Software Changes!




All Rights Reserved

CSE7315M31

What Causes Change?• Improvement in quality• Functionality enhancement• Requirements Changes• Several variations of the same

software may have to be maintained in order to support multiple hardware platforms

Release 1 Release 4Release 3Release 2




All Rights Reserved

CSE7315M31

Additional Causes of Change

• Maintenance• Enhancement• Fixing Bugs• Requirements Changes• etc.

Release 1 Release 4Release 3Release 2




All Rights Reserved

CSE7315M31

Another Issue• You may create two versions of the same

product for different applications• Over time they “drift apart” and become

less and less compatible or consistent• You can maintain as different products or

maintain as variants of the same product• But the variant approach fades in

suitability over time, as the similarities are reduced

Release 1Release 2a

Release 2b Release 3b

Release 3a

Release 4b

Release 4a




All Rights Reserved

CSE7315M31

“Any system subject to change will lose order

and will migrate toward chaos, unless you add

effort [cost, energy] to maintain integrity.”

The Entropy Principal

• This principal is based on the entropy principle of physics (for you scientists)

• or the second law of thermodynamics (for you engineers)

• or on basic principles of management (for you businessmen).

• Everyone else will just need to believe it.




All Rights Reserved

CSE7315M31

cl

cm co

cn ck

cj

ci

Inherent Instability• Suppose you have a system with components

c1, c2, ..., cn

• And suppose p[i,j] is the probability that a change to component i will result in an error in the behavior of component j

• What is the probability that a change in the system will result in introduction of an error?




All Rights Reserved

CSE7315M31

Solution- the Eigenvalue of the Following Matrix

c2 c3c1...

c1

c2

c3

..

.

p1,

2

p1,

3p2,

2

p1,

1

p3,

1

p2,

1




All Rights Reserved

CSE7315M31

Characteristics• Probability goes up as the square of the

number of system components (SW size)– i.e., doubling the size quadruples the

probability of error when making a change

• Probability goes up as the p[i,j] values get larger– i.e., modularity (minimum interdependence)

helps reduce the likelihood of errors

Although not provable from the statistics, experience shows that the more people involved in development, the larger the pi,j values. Mainly due to complexity.

Although not provable from the statistics, experience shows that the more people involved in development, the larger the pi,j values. Mainly due to complexity.




All Rights Reserved

CSE7315M31

Inherently Unstable Systems

• Eigenvalue exceeds 1 -- any change will probably introduce more errors than it corrects

• This happens with size, complexity, and lack of modularity

• These are the motivating principals behind many forms of complexity analysis, such as McCabe metrics for cohesion, etc.




All Rights Reserved

CSE7315M31

How to Keep Software from Deteriorating?

Worst Case Scenario:Discard and redo when the system

reaches inherent instability

This is a universal principle.It applies to software, to computer

systems, to governments, and even to species

This is a universal principle.It applies to software, to computer

systems, to governments, and even to species




All Rights Reserved

CSE7315M31

Note …• Some e-commerce software is exactly

like this – that is, it is designed for a very short lifetime and is thrown away – Web sites may fit this pattern– Games and entertainment software– Short-lived applications

For applications such as these, configuration management is still

needed during development, but it generally need not be so rigorous.

For applications such as these, configuration management is still

needed during development, but it generally need not be so rigorous.




All Rights Reserved

CSE7315M31


Maintenance Strategy:Invest effort to preserve integrity (helps stave off the time when you

must resort to the worst case scenario)

Example: if you maintain your car well, it might last 20 years; if you don’t, it

might last 5 years

Example: if you maintain your car well, it might last 20 years; if you don’t, it

might last 5 years




All Rights Reserved

CSE7315M31

Note …

• Configuration management is one of the critical elements of a maintenance strategy.– Identifies and preserves the integrity

of the system

For applications with a long maintenance period, good configuration management is

needed during development and during maintenance.

For applications with a long maintenance period, good configuration management is

needed during development and during maintenance.




All Rights Reserved

CSE7315M31


Design for Maintainability Strategy:Design the system to minimize the

cost and impact of maintenance and change (reduces the cost of

the maintenance strategy)

Among other things, this entails better communication, coordination,

and management of change - i.e., configuration management

Among other things, this entails better communication, coordination,

and management of change - i.e., configuration management




All Rights Reserved

CSE7315M31

Possible Exam Question

Explain why change causes software to deteriorate

Define and explain three steps you can take to manage the inherent tendency of software to deteriorate




All Rights Reserved

CSE7315M31

Product Terminology Illustrated

System

Subsystem 1

SW Item 2 SW Item 3SW Item 1

Subsystem 2 Subsystem 2

Component 2 Component 3Component 1

SW Item 4

Module 2Module 1




All Rights Reserved

CSE7315M31

Terminology for the Product

System or Product– The package of all elements that meets

the user’s requirements - e.g., a radar system

Subsystem– The highest level of decomposition of

system’s functionality e.g. antenna, signal processing system etc.




All Rights Reserved

CSE7315M31

Terminology for the Product (continued)

Software Item or Software Configuration Item or Software Product– The next level of decomposition, still

allowing independence - e.g., software, digital & analog products in a signal processing system




All Rights Reserved

CSE7315M31

Terminology for the Product(continued)

Component– The next level of decomposition below the

product– In addition to source code elements,

components for software products include specifications, test cases and documentation

Module or Unit– The lowest level of decomposition managed

by the SCM system. – Typically refers to source code, but could

include chapters of a document and such




All Rights Reserved

CSE7315M31

• All elements that make up or relate to a version of a product– The proper version of each:

� document� compiler used to develop� development tool� data set used for

simulating� special equipment� operating system

� test code� test data� library� procedur

e� hardware� etc.

� module� component� data file� macro� simulator� specification

Configuration




All Rights Reserved

CSE7315M31

Physical Configuration

• The proper files, documents, tools, and other components that constitute the software or that are needed to produce the software

Functional Configuration• The correct capabilities and

functionalities for a given version of the software




All Rights Reserved

CSE7315M31

NewBaseline

WorkingVersionWorking

Version

WorkingVersion

. . .

. . .

. . .

Baseline

Baseline• The established, official, current

version of a product configuration• Serves as point of departure or

reference for subsequent development or changes




All Rights Reserved

CSE7315M31

Revision vs. VariationRevision– A version of a product created with a

clear intent to supercede the previous one

– Usually numbered for identification

Variation– A version that fulfills the same

purpose but for a slightly different situation

– Identification is usually achieved by giving each variation a name representative of its uniqueness




All Rights Reserved

CSE7315M31

Summary of Module• Software Configuration Management is

the process of identifying, organizing and managing modifications to software

• The purpose of configuration management is to maintain integrity of the product by controlling change to the product

• Unmanaged change is very possibly the largest single cause of failure to deliver systems on time and within budget

• Entropy means change leads to chaos unless we inject energy (management)




All Rights Reserved

CSE7315M31

References• Ben-Menachem, Mordechai, Software CM

Guidebook, McGraw Hill Book Co., 1994, ISBN 0-07-709013-6, LC# 94-001102

• Compton, Stephen B. & Guy Conner, CM for Software, Van Nostrand Reinhold, 1994, ISBN 0442017464

• Dart, Susan A., "Achieving the Best Possible Configuration Management Solution," CrossTalk, Vol 9 #9 (September, 1996).

• Esterbrook, Steve,The Configuration Management (CM) Resource Guide, 1999, http://www.quality.org/config/cm-guide.html




All Rights Reserved

CSE7315M31

References (continued)

• Marshall, A. J., "Demystifying Software Configuration Management." CrossKeys, Vol 8 #5, (May, 1995).

• NASA, Software Configuration Management Guidebook, 1995, http://satc.gsfc.nasa.gov/GuideBooks/cmpub.htm

• Parnas, David Lorge. "Software Aging." Proceedings of the 16th international conference on Software Engineering, 1994, pp. 279-287.

cse 7315 - sw project management / module 31 - software configuration management principles...

Documents