1. 12/06/20051 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.

2. 12/06/20052 Configuration management Configuration management planning –Configuration item identification –The configuration database Change management Version and release management System building

3. 12/06/20053 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.

4. 12/06/20054 Version and release management Version identification 1.Version numbering 2.Attribute-based identification 3.Change-oriented identification  Release Management –Release decision-making –Release creation –Release documentation

5. 12/06/20055 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

6. 12/06/20056 1.Assign individuals to configuration items 2.Check out configuration items 3.Make the change 4.Review the change 5.Check in the configuration items that have been changed 6.Established a baseline for testing 7.Perform quality assurance and testing activities 8.Promote changes for inclusion in next release 9.Rebuild appropriate version of software 10.Review the change to all configuration items 11.Include changes in new version 12.Distribute the new version

7. 12/06/20057 Software Change Requirements analysis System and software design Implementation and 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

8. 12/06/20058 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

9. 12/06/20059 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

10. 12/06/200510 Multiple Views of Impact Analysis Managers –Cost of change implementation Team leaders –Affected subsystems and teams Programmers –Affected code sections Maintainers –Affected test cases

11. 12/06/200511 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. 12/06/200512 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

13. 12/06/200513 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

14. 12/06/200514 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 GGraph G* (Transitive Closure of G) Module A Module BModule C Module DModule A Module BModule C Module D

15. 12/06/200515 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)

16. 12/06/200516 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++;

17. 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 of variable v at point p. The forward slice w.r.t variable v at program point p The program subset that may be influenced by the value of variable v at point p.

18. 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)”

19. 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

20. 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”

21. 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

22. 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?

23. 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

24. 12/06/2005 Backward 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); } Enter sum = 0i = 1 while(i < 11) printf(sum) printf(i) sum = sum + ii = i + i T T T T T T T T

25. 12/06/2005 Backward 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); } Enter sum = 0 i = 1 while(i < 11) printf(sum) printf(i) sum = sum + i i = i + i T T T T T T T T

26. 12/06/2005 Backward 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); } Enter sum = 0 i = 1 while(i < 11) printf(sum) printf(i) sum = sum + i i = i + i T T T T T T T T

27. 12/06/2005 Backward 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); } Enter sum = 0 i = 1 while(i < 11) printf(sum) printf(i) sum = sum + i i = i + i T T T T T T T T

28. 12/06/2005 Slice Extraction int main() { int i = 1; while (i < 11) { i = i + 1; } printf(“%d\n”,i); } Enter i = 1 while(i < 11) printf(i) i = i + i T T T T T

29. 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)”

30. 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)”

31. 12/06/200531 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

32. 12/06/200532 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

33. 12/06/200533 Corrective Maintenance Suppose that the maintenance programmer has located the fault Problem: –How to fix it without introducing a regression fault

34. 12/06/200534 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

35. 12/06/200535 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

36. 12/06/200536 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

37. 12/06/200537 Corrective Maintenance (contd) Major skills are required for corrective maintenance –Superb diagnostic skills –Superb testing skills –Superb documentation skills

38. 12/06/200538 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

39. 12/06/200539 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

40. 12/06/200540 Maintenance Cost :Technical Factors Module Independence Programming language Programming style Program validation Documentation Configuration Management

41. 12/06/200541 Maintenance Cost : Non-technical factors Application domain Staff stability Program age External environment Hardware stability

42. 12/06/200542 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.

43. 12/06/200543 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