1. CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M31 Slide 1 August 13, 2006 SMU CSE 7315 Planning and Managing a Software Project Module 31 Software Configuration Management Principles

2. CSE7315M31 Slide # 2August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Objective of This Module To discuss basic principles of software configuration management: Text, chapters 7, 12

3. CSE7315M31 Slide # 3August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved What Is Software Configuration Management? Definition: Software Configuration Management is the process of identifying, organizing and managing modifications to software

4. CSE7315M31 Slide # 4August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Purpose of Configuration Management The purpose of configuration management is to maintain integrity of the product by controlling change to the product

5. CSE7315M31 Slide # 5August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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 procedure hardware etc. module component data file macro simulator specification If any of the above is wrong, the product lacks integrity and may not work

6. CSE7315M31 Slide # 6August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved What is Integrity? Having the right parts that all fit together to form a correct product. ListingUser’s Guide Main, rel 2.3 Sub1, rel 1.7 Sub2, rel 3.1... Object code

7. CSE7315M31 Slide # 7August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

8. CSE7315M31 Slide # 8August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Examples of Loss of Integrity Possible Cause(s)Example 6, 7Performance 2 years ago cannot be duplicated with the current release 2,3Source code will not compile without errors 2,3Source code will not link without errors 2,3Source code will not execute without errors 2,3Compiled code will not execute with the same results as the released code

9. CSE7315M31 Slide # 9August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved More Examples of Loss of Integrity Possible Cause(s)Example 2,3Compiled code has different object code or code size from released code 1A bug that we fixed once before has reappeared 1,2,5Code does not match the design specification 1,5 Design does not match requirements spec.

10. CSE7315M31 Slide # 10August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved More Examples of Loss of Integrity Possible Cause(s)Example 1, 7A feature that we added and fully tested has suddenly stopped working 2It worked in the factory but not in the field 1All records of a particular feature are gone, and the programmer/designer left the company 2,4You cannot figure out which version of each module is needed to reproduce a problem we found in the field

11. CSE7315M31 Slide # 11August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Possible Causes of Integrity Problems NumberCause 1Simultaneous 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

12. CSE7315M31 Slide # 12August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

13. CSE7315M31 Slide # 13August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved More Possible Causes of Integrity Problems NumberCause 2 Multiple uses of an updated module. -- Perhaps not all copies were changed -- Perhaps because not all were known. 3Multiple users of an updated module -- Not all notified and perhaps not all are known. These are examples of the double maintenance problem.

14. CSE7315M31 Slide # 14August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

15. CSE7315M31 Slide # 15August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

16. CSE7315M31 Slide # 16August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Another Multiple Use Problem Change 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.

17. CSE7315M31 Slide # 17August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved More Possible Causes of Integrity Problems Number Cause 4Multiple 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.

18. CSE7315M31 Slide # 18August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved More Possible Causes of Integrity Problems Number Cause 5Changes to code were not reflected in other development artifacts (design, user guide, etc.) 6Failure to keep track of versions or to control changes to the software

19. CSE7315M31 Slide # 19August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved More Possible Causes of Integrity Problems Number Cause 7Shared 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

20. CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M31 Slide 20 August 13, 2006 There are Fundamental Reasons Why These Problems Happen Software Changes!

21. CSE7315M31 Slide # 21August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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 1Release 4Release 3Release 2

22. CSE7315M31 Slide # 22August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Additional Causes of Change Maintenance Enhancement Fixing Bugs Requirements Changes etc. Release 1Release 4Release 3Release 2

23. CSE7315M31 Slide # 23August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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 1 Release 2a Release 2bRelease 3b Release 3a Release 4b Release 4a

24. CSE7315M31 Slide # 24August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved “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.

25. CSE7315M31 Slide # 25August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved c l c m c o c n c k c j c i Inherent Instability Suppose you have a system with components c 1, c 2,..., c n 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?

26. CSE7315M31 Slide # 26August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Solution- the Eigenvalue of the Following Matrix c2c2 c3c3 c1c1... c1c1 c2c2 c3c3 p 1,2 p 1,3 p 2,2 p 1,1 p 3,1 p 2,1

27. CSE7315M31 Slide # 27August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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.

28. CSE7315M31 Slide # 28August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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.

29. CSE7315M31 Slide # 29August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

30. CSE7315M31 Slide # 30August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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.

31. CSE7315M31 Slide # 31August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

32. CSE7315M31 Slide # 32August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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.

33. CSE7315M31 Slide # 33August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

34. CSE7315M31 Slide # 34August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

35. CSE7315M31 Slide # 35August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Configuration Management Terminology

36. CSE7315M31 Slide # 36August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Product Terminology Illustrated System Subsystem 1 SW Item 2 SW Item 3 SW Item 1 Subsystem 2 Component 2Component 3 Component 1 SW Item 4 Module 2Module 1

37. CSE7315M31 Slide # 37August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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.

38. CSE7315M31 Slide # 38August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

39. CSE7315M31 Slide # 39August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

40. CSE7315M31 Slide # 40August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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 procedure hardware etc. module component data file macro simulator specification Configuration

41. CSE7315M31 Slide # 41August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

42. CSE7315M31 Slide # 42August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved New Baseline Working Version Working Version Working Version... Baseline The established, official, current version of a product configuration Serves as point of departure or reference for subsequent development or changes

43. CSE7315M31 Slide # 43August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved Revision vs. Variation Revision – 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

44. CSE7315M31 Slide # 44August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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)

45. CSE7315M31 Slide # 45August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved END OF MODULE 31

46. CSE7315M31 Slide # 46August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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

47. CSE7315M31 Slide # 47August 13, 2006 CSE 7315 - SW Project Management / Module 31 - Software Configuration Management Principles Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved 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.