Upload
paula-adams
View
221
Download
0
Embed Size (px)
Citation preview
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
Slide # 3August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 4August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 5August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 6August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 7August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 8August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 9August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 10August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 11August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 12August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 13August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 14August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 15August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 16August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 17August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
More Possible Causes of Integrity Problems
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.
Slide # 18August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
More Possible Causes of Integrity Problems
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
Slide # 19August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
More Possible Causes of Integrity Problems
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!
Slide # 21August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 22August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
Additional Causes of Change
• Maintenance• Enhancement• Fixing Bugs• Requirements Changes• etc.
Release 1 Release 4Release 3Release 2
Slide # 23August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 24August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 25August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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?
Slide # 26August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 27August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 28August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 29August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 30August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 31August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
How to Keep Software from Deteriorating?
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
Slide # 32August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 33August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
How to Keep Software from Deteriorating?
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
Slide # 34August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 35August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
Configuration Management Terminology
Slide # 36August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 37August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.
Slide # 38August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 39August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 40August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 41August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 42August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 43August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 44August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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)
Slide # 45August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
CSE7315M31
END OFMODULE 31
Slide # 46August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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
Slide # 47August 13, 2006
CSE 7315 - SW Project Management / Module 31 - Software Configuration
Management PrinciplesCopyright © 1995-2006, Dennis J. Frailey,
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.