Presentation is loading. Please wait.

Presentation is loading. Please wait.

Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 1 Configuration and Change Management Managing the products of system.

Similar presentations


Presentation on theme: "Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 1 Configuration and Change Management Managing the products of system."— Presentation transcript:

1 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 1 Configuration and Change Management Managing the products of system change

2 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 2 Topics covered  Configuration management fundamentals  Software and documentation version control  Configuration management planning (SCMP)  Change management  System building  CASE tools for configuration management

3 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 3  New versions of software systems are created as they change  For different machines/OS  Offering different functionality  Tailored for particular user requirements  Configuration management is concerned with managing evolving software systems  System change is a team activity  CM aims to control the costs and effort involved in making changes to a system Configuration Management

4 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 4 Configuration Items (CI’s) Units tracked officially  down to the smallest unit worth tracking  includes most official documents A1 S6 E3 C4 D5 Payroll v. 0.3.4.2 Payroll v. 0.4.1.0 Payroll v. 0.3.4.3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

5 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 5 Configuration Items (CI’s) Units tracked officially  down to the smallest unit worth tracking  includes most official documents A1 S6 E3 C4 D5 A1 S7 E3 C4 D5 Payroll v. 0.3.4.2 Payroll v. 0.4.1.0 Payroll v. 0.3.4.3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Module updated

6 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 6 Configuration Items (CI’s) Units tracked officially  down to the smallest unit worth tracking  includes most official documents A1 S6 E3 C4 D5 A1 S7 E3 C4 D5 Payroll v. 0.3.4.2 A1 D5 Payroll v. 0.4.1.0 S7 C4 E3 F1 Payroll v. 0.3.4.3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Module added

7 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 7 Configuration Management Requirements  Locking - to prevent more than one person working on a CI at one time  Check out - authorization  Check-in procedure  Authorization  May inforce testing  Historical record of prior groupings of consistent CI’s  For a list of CM tools: http://dmoz.org/Computers/Software/Configurati on_Management/Tools/ Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 8 System Families

9 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 9 CM Standards  CM should always be based on a set of standards which are applied within an organisation  Standards should define how items are identified, how changes are controlled and how new versions are managed  Standards may be based on external CM standards (e.g. IEEE standard for CM)  Existing standards are based on a waterfall process model - new standards are needed for evolutionary development  For further info see http://www.rspa.com/spi/SCM.html http://www.rspa.com/spi/SCM.html

10 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 10 IEEE 828-1990 SCMP Table of Contents 3.2 Configuration control 3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or dis- approving changes 3.2.4 Implementing changes 3.3 Configuration status accounting 3.4 Configuration audits & reviews 3.5 Interface control 3.6 Subcontractor / vendor control 4. SCM schedules 5. SCM resources 6. SCM plan maintenance 1. Introduction 2. SCM management 2.1 Organization 2.2 SCM responsibilities 2.3 Applicable policies, directives & procedures 3. SCM activities 3.1 Configuration identification 3.1.1 Identifying configu- ration items 3.1.2 Naming configu- ration items 3.1.3 Acquiring configu- ration items Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 11 Plan Configuration Management 1. Roughly sketch out your SCMP Determine procedures for making changes Omit tool references unless already identified one See the case study for an example 2. Specify what you need from a CM tool For class use, maybe only locking and backup 3. Evaluate affordable tools against your needs and budget Commercial tools are in wide use (here is a list)here is a list For class use, try free document storage web sites; try simple method of checking out e.g. renaming 5. Finalize your SCMP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 12  Software systems are subject to continual change requests  From users  From developers  From market forces  Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost-effective way Change Management

13 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 13 The Change Management Process

14 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 14 The Change Management Process

15 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 15 The Change Management Process

16 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 16 The Change Management Process

17 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 17  CRF form layout is part of the CM planning process  Records from the requestor:  change requirement (description)  requestor’s name  reason for change  Urgency  Records from the development team:  evaluation of change requirement  assessment / impact analysis – technical/opertaional feasibility  change cost estimate  recommendation Change Request Form

18 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 18 Change Request Form

19 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 19 Assessment portion of Change Request Form  Assessment  Technical impact on design, code, testing, etc  Risks associated with change  External impact on users and operators  Estimate  Effort and resources  Costs  Schedule

20 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 20  Differs from CM tools like CVS  A major problem in change management is tracking change status  Change tracking tools keep track of the status of each change request and automatically ensure that change requests are sent to the right people at the right time.  Integrated with E-mail systems allowing electronic change request distribution Change Tracking Tools

21 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 21  Changes should be reviewed by an external group who decide whether or not they are cost-effective from a strategic and organizational viewpoint rather than a technical viewpoint  Should be independent of project responsible for system. The group is sometimes called a change control board  May include representatives from client and contractor staff Change Control Board

22 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 22  Record of changes applied to a document or code component  Should record, in outline, the change made, the rationale for the change, who made the change and when it was implemented  May be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically Derivation History

23 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 23 Component Header Information

24 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 24 Change Request Form - P1 Project: Registration SystemNumber: 0023 Change requester:DLSDate: 3/28/2005 Description: We would like the system to be played by more than one user at a time over a network. Change priority: high

25 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 25 Change Request Form - P2 Project: Registration SystemNumber: 0023 Change Assessment: Analyst:Analysis Date:  Technical impact on design, components, code, testing, etc  Risks associated with change  External impact on users and operators  Effect on resources  Effect on costs  Effect on schedule

26 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 26 ONE WAY … Change Request Form - P2 Project: Registration SystemNumber: 0023 Change Assessment: Analyst:Analysis Date:  Technical impact on design, components, code, testing, etc  Network centric change in architecture from single system arch  Player against player  Multi-tasking (threaded) code for concurrent execution of player paths  Risks associated with change  Delay in response time of game  Currently lack human resources to affect change (can we get them)  Server crash means everyone is down  Potential for players cheating  External impact on users and operators  Will now need a network  Will need an administration person  Game is potentially more complex due to player-player interactions

27 Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 27 ONE WAY … Change Request Form - P2 Project: Registration SystemNumber: 0023 Change Assessment: Analyst:Analysis Date:  Effect on develop resources  Human  A developer with network computing expertise  Physical  A server (for at least testing)  A system for simulating multiple users  A DBMS will be needed (for the game and for financial account)  Network hardware / connection  Addition infrastructure for added human and physical resources  Effect on costs  Hardware = $5000  Human = $60,000*1.30 / 220 * 10 mandays = $3500  Training/Travel = $2500  Infrastructure = $2000  Project management overhead ~ 10% of $13,000 = $1300  Effect on schedule  Approximately 1 month


Download ppt "Adapted from Software Engineering, 6th edition. Chapter 29, by Ian Sommerville Slide 1 Configuration and Change Management Managing the products of system."

Similar presentations


Ads by Google