1. Change/Version Management INFT13/73-316 Bond University © 1998 - 2003 K. J. Ross & Associates Pty Ltd

2. 2 - Lect 3 Overview  Software Configuration Management  Change Processes  Versioning  CM Plans

3. 3 - Lect 3 Software Development and Change No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle. Bersoff, et al, 1980 Software development involves change –A defect to be fixed –An existing function to be enhanced –A new feature to be added –A new platform to support –A customer-driven special project –Internationalization

4. 4 - Lect 3 Change Causes Developers Pain Working in isolation, you can’t “see” code changes made by team members You can’t work in parallel on files that a co-worker is modifying You frequently lose time and have to redo work because of lost defects or overwritten code You have trouble determining which versions of the code you should be working on You have difficulty answering your manager’s questions about project status You don’t know who on the team is working on what You have no idea which versions of files went into a build

5. 5 - Lect 3 Software Configuration Management Software Configuration Management is a discipline for controlling the evolution of software systems.

6. 6 - Lect 3 Software Configuration Management Standard definition for CM taken from IEEE standard 729-1983[SCM] includes: –Identification: identifies structure of the product, its components and its type, making it unique (CI*). Addresses “What version of the file is this?” –Control: Manages release of a product and changes done throughout the life cycle. Uses baseline** product. Addresses “What changes went into the latest version of this product ?” –Status Accounting: Recording and reporting the status of components & change requests. Addresses “How many files were affected by fixing this bug?” –Audit and Review: Maintaining consistency, validating completeness of components that form a product. Addresses “Are all the correct versions of files used in this current release?”

7. 7 - Lect 3 SCM Definitions *Configuration Item - collection of hardware, software, and/or firmware, which satisfies an end-user function and is designated for configuration management. **Baseline - collections of configuration items at a particular point in time

8. 8 - Lect 3 Benefits of SCM A modern CM solution can provide companies with many benefits such as : –Providing integrity and hence improving the complete software development and maintenance cycle. –Parallel planning and development. Offshore, distributed development. –Management of change complexity and its evolution. –Making testing and QA structured and easier. –Removing error-prone steps from product release management. –Providing traceability of related components. –Automating the CM processes and procedures. –Dramatically easing change management and problem tracking challenges. Support for variant baselines. –** More responsive to customers’ growing need for bug fixes, enhancements and support.

9. 9 - Lect 3 References IEEE STD 610.12-1990, "IEEE Standard Glossary of Software Engineering Terminology." ISO 10007:1995 (E), "Quality Management - Guidelines for Configuration Management.“ Rigg, W., C. Burrows, and P. Ingram, Ovum Evaluates: Configuration Management Tools, Ovum Limited, 1995 Susan Dart - The Past, Present & the future of CM– Dart Technology Strategies, Inc. Susan Dart – Achieving the best CM solution – Dart Technology Strategies, Inc. Bob Ventimiglia, Effective Software Configuration Management Ovum.com – Product Evaluation http://www.ovum.com/go/product/sample/0048437.htm

10. 10 - Lect 3 Overview  Software Configuration Management  Change Processes  Versioning  CM Plans

11. 11 - Lect 3 Change Control Process Need for change is recognised Change request from user Developer evaluates Change report is generated User is informed Change request is denied Change control authority decides Request is queued for action Assign people to SCIs Make the change Check-in the SCIs Review/audit the change Perform SQA/Testing activities Establish a baseline for testing Check out SCIs Promote SCIs for inclusion in next release Rebuild appropriate version Review/audit the change Include all changes in release

12. 12 - Lect 3 Change Request A change request form is used to capture the intended change Used as a tracking/audit mechanism

13. 13 - Lect 3 Configuration Control Board Necessary on larger projects Performs evaluation, approval, triage –Evaluate cost, resourcing, impact, risk Approves all baseline changes Can be excessively loaded on large projects How often should you meet?

14. 14 - Lect 3 Iteration and Release Planning Plan out iterations and releases against change requests

15. 15 - Lect 3 Change Tracking Software Bugzilla ClearQuest Many others See http://testingfaqs.org/t-track.html

16. 16 - Lect 3 Overview  Software Configuration Management  Change Processes  Versioning  CM Plans

17. 17 - Lect 3 The Release Process 1.0 1.1 1.2 2.0 Change Requests, Defects Release Candidate: Test Completed  (delta) Release Candidate: what new tests??? What’s new? What components have changed? What is the impact of the changes? What tests were completed previously?

18. 18 - Lect 3 Change Log Show revisions Diff indicates changes to files and folders between each build Change messages can be kept –Often trace back to change request / defect report

19. 19 - Lect 3 Diffs

20. 20 - Lect 3 Workspaces Developers check-out code from a shared repository into their own workspace Enables them to work independently Check-in code when complete

21. 21 - Lect 3 Simultaneous Update When 2 developers change at the same time changes can be lost

22. 22 - Lect 3 Locking Models Locking is too restrictive –Forget to cancel lock –Unneccessary serialisation

23. 23 - Lect 3 Copy Merge Simultaneous updates cause a conflict –Second write creates conflict when commit is attempted

24. 24 - Lect 3 Copy Merge Update is performed Conflict is highlighted Conflict is resolved by merging changes Changes are committed Other users get merged changes on their next update

25. 25 - Lect 3 Updates and Commits Updates refresh workspace with latest changes Commit is performed to check-in changes Change Conflicts

26. 26 - Lect 3 Branching and Merging Branches are separate development streams –Allows part of the development team to continue developing future changes/enhancements in the main line of the archive while another part of the team makes changes that only apply to the branch. –Branching also provides reproducibility, allowing developers to “go back in time” and check out source code as it existed at any point. This makes it possible to recreate a previous version of the product, regardless of the number of subsequent changes, additions, or deletions to the project. A merge later synchronises changes back into the main development path MERGE 0 1 2 3 5 6 7 0 1 0 1 2 4 2 / special / main file101.c BRANCHES / rls2_bugfix

27. 27 - Lect 3 Versioning Tools  Subversion  http://subversion.tigris.org/  Windows GUI - http://tortoisesvn.tigris.org/  Eclipse PlugIn - http://subclipse.tigris.org/  CVS  http://www.cvshome.org  DaRCS  http://darcs.net  Many others  Visual Source Safe, Clearcase, PVCS, RCS, SCCS, Continuous, …

28. 28 - Lect 3 Overview  Software Configuration Management  Change Processes  Versioning  CM Plans

29. 29 - Lect 3 CM Planning Activities Four main activities in planning a CM approach Identification Control Status Accounting Audit and Review

30. 30 - Lect 3 CM Identification Identification of all the components and their versions, baselines and configurations which represent the systems  Specifications, designs, code  User manuals, operational instructions, installation procedures  Inspection reports, change requests, problem statements  Test plans, stubs, harnesses, test data Identify the configurations of different components that make up a product –e.g. a parts list describing the versions of subcomponents used

31. 31 - Lect 3 CM Identification Identify the attributes that can be assigned to components –e.g. whether a variant for a specific platform, such as Windows vs. Unix specific variants. Define how the components can be stored in a repository –what directory hierarchies are used for supporting projects and the different kinds of information in a project.

32. 32 - Lect 3 CM Control Describes how changes to components of software development and testing activities are controlled  How to access the components  e.g. release components only found in a particular repository  Who can access components  e.g. authority to hand components over to testers/release.  When components can be accessed  e.g. the preconditions to be satisfied before release of the system, configuration of system under test is frozen while testing  Assessment of the impact of proposed changes  e.g. reviews of proposed changes made and approval granted prior to changes being made.

33. 33 - Lect 3 CM Control CM control is established through defined procedures, for example:  Configuration Control Boards  Change requests/authorizations

34. 34 - Lect 3 CM Status Accounting Reporting functions for assessing state of development configurations  When development phases are complete  e.g. whether system testing phase is complete  Components tested  e.g. all those modules which have undergone unit testing.  Work pending  e.g. notification that a system configuration has changed since the released/tested configuration  Changes requested  e.g. what changes remain pending for a component to decide whether the testing/release should be postponed

35. 35 - Lect 3 CM Audit and Review Verifies whether:  The configuration is complete  e.g. all components necessary for release are included.  The configuration is a consistent set of parts.  e.g. specifications packaged with a system ready for release are the correct version.

36. 36 - Lect 3 Overview  Software Configuration Management  Change Processes  Versioning  CM Plans

37. 37 - Lect 3 Putting It All Together To Do List Organized Activities RequestPriorityOwnerProject Bug 981SamWebRelay Bug 5273SandyWebRelay Add GUI button1KimWebRelay Add GUI button1KimWebRelay Bug 98 New GUI Button Bug 527 System Acceptance Production Work On CommitCommit Make Baseline Promote Baseline UpdateUpdate Baseline Developers Integrator Project Manager