12/06/20051 Software Configuration Management Configuration management (CM) is the process that controls the changes made to a system and manages the different.

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

Configuration Management Managing Change. Points to Ponder Which is more important?  stability  progress Why is change potentially dangerous?
1 Postdelivery Maintenance Xiaojun Qi. 2 Why Postdelivery Maintenance Is Necessary Corrective maintenance: To correct residual faults –Analysis, design,
Software Configuration Management
SE 555 Software Requirements & Specification Requirements Management.
CSC 395 – Software Engineering Lecture 25: SCM –or– Expecting Change From Everything But Vending Machines.
Software Configuration Management (SCM)
1 Software Requirements Specification Lecture 14.
Configuration Management
Chapter 27 Change Management
Software maintenance Managing the processes of system change.
Software Configuration Management
CSSE 375 Software Construction and Evolution: Configuration Management
Configuration Management Avoiding Costly Confusion mostly stolen from Chapter 27 of Pressman.
Chapter 9 – Software Evolution and Maintenance
This chapter is extracted from Sommerville’s slides. Text book chapter
SE-02 CONFIGURATION MANAGEMENT Today we talk about Software Configuration Management (SCM for short): - What? - Why? - How?
System Analysis and Design
Software Configuration Management
CPIS 357 Software Quality & Testing
What is a life cycle model? Framework under which a software product is going to be developed. – Defines the phases that the product under development.
Software Engineering CS3003 Lecture 3 Software maintenance and evolution.
Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
Testing Workflow In the Unified Process and Agile/Scrum processes.
This chapter is extracted from Sommerville’s slides. Text book chapter
Chapter 13: Regression Testing Omar Meqdadi SE 3860 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Software Engineering 2003 Jyrki Nummenmaa 1 CONFIGURATION MANAGEMENT Today we talk about Software Configuration Management (SCM for short): -
SOFTWARE CONFIGURATION MANAGEMENT. Change is inevitable when computer software is built. And change increases the level of confusion among software engineers.
©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Configuration management.
Software Project Management
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Software Maintenance Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
HNDIT23082 Lecture 06:Software Maintenance. Reasons for changes Errors in the existing system Changes in requirements Technological advances Legislation.
Objectives Understand Corrective, Perfective and Preventive maintenance Discuss the general concepts of software configuration management.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
System Maintenance Modifications or corrections made to an information system after it has been released to its customers Changing an information system.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
CS451 Software Maintenance Yugi Lee STB #555 (816) Note: This lecture was designed based on Stephen Schach’s.
Configuration Management
© SERG Reverse Engineering (Software Maintenance & Reengineering) Software Maintenance Managing the processes of system change.
Configuration & Build Management. Why Software Configuration Management ? The problem: Multiple people have to work on software that is changing More.
Software Configuration Management (SCM)
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Configuration Management
Software Configuration Management
Software Configuration Management
Software Project Configuration Management
Software Configuration Management (SCM)
8.4 Management of Postdelivery Maintenance
Chapter 11: Software Configuration Management
Chapter 18 Maintaining Information Systems
Configuration Management
Software Configuration Management
Chapter 27 Change Management
Lecture 3 Change Management
Software Configuration Management
Chapter 27 Change Management
How is a PDG Created? Control Flow Graph (CFG) PDG is union of:
Chapter 27 Change Management
Chapter 11: Software Configuration Management
Chapter 27 Change Management
Lecture 06:Software Maintenance
Chapter 27 Change Management
Software Configuration Management
Presentation transcript:

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.

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

12/06/20053 Baselines IEEE std. NO : 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/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

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

12/06/ 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

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

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

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

12/06/ 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/ 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/ 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/ 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/ 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

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

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

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

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

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

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

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/ 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/ 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/ Corrective Maintenance Suppose that the maintenance programmer has located the fault Problem: –How to fix it without introducing a regression fault

12/06/ 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/ 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/ 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/ Corrective Maintenance (contd) Major skills are required for corrective maintenance –Superb diagnostic skills –Superb testing skills –Superb documentation skills

12/06/ 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/ 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/ Maintenance Cost :Technical Factors Module Independence Programming language Programming style Program validation Documentation Configuration Management

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

12/06/ 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/ 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