SE603 – Software Management Virtual Class #8

1. SE603 – Software Management Virtual Class #8 Mohammad El-Ramly, PhD

2. تذكرة وهو معكم أينما كنتم والله بما تعملون بصير يعلم خائنة الأعين و ما تخفى الصدور

3. Lecture 4Outline • Definition of SCM • Version Control • Change Management • Backup Plan • Release Planning

5. Software is Dynamic • Software is dynamic • Requirements change • Design changes • Code changes

6. 1. SCM • Also known as software change, configuration and release management. • This includes two main activities • Change management • Configuration management • Some times, release planning is also included.

7. SCM Definition • SCM management is the practice of identifying project artifacts and handling changes systematically so that a system can maintain its integrity over time. • It includes techniques for • evaluating proposed changes, • tracking changes, and • keeping copies of the system as it existed at various points in time.

8. SCM Definition • Software Configuration Management encompasses the disciplines and techniques of initiating, evaluating and controlling change to software products during and after a software project

9. Important Definitions • We will define the following terms * • Configuration item • Version, baseline • Version control, workspace • Check in, check out, branch, merge • Build, building, release, release management, • Change request, CCB, impact analysis * The definitions are taken from IEEE standards and Glossary of terms used in Configuration Management by iNTCCM

10. SW Configuration Item 1 • Computer programs • both source and executable • Documentation • both technical and user • Data • within a program or external to it

11. SW Configuration Item • A configuration item (CI) is an item or aggregation of hardware or software or both that is designed to be managed as a single entity in the configuration management process. • This includes all types of items, e.g., to source code, test suites, documents, resources, etc.

12. Definitions • Software version: A version of a software item (CI) is an identified instance of that item. • Baseline: A specification or software product that has been formallyreviewed or agreedupon, that thereafter serves as the basis for further development, and that can be changed only through a formal change control process. 2 3

13. Definitions • Version control. A process for keeping different versions in a CI class, without formal control of the changes between versions. A basic activity needed within configuration management. • Workspace. A workspace represents a configuration controlled area copy and acts as an environment where one can work isolated for a task duration. 4 5

14. Definitions • Check in. Storing a configuration item in the configuration controlled area. • Check out. Copy of a configuration item from the configuration controlled area. • Branch. A separate development line, e.g. to isolate bug fixing of an already delivered release from further development. • Merging. The consolidation of different development branches. 6 7 8 9

15. Definitions • Build. An operational version of a software product incorporating a specified (sub)set of the capabilities that the final product will include. • Building. Assembling a system or part of a system from components placed under configuration management. 10 11

16. Definitions • Release. The formal notification and distribution of an approved version of a hardware/software system. • Release Management. The discipline to manage the release cycles of the product or part of the product; this refers to planning and actual releasing 12 13

17. Definitions • Change Request (CR). A formal request for a change to be implemented in a specific configuration item approved by the CCB and based on a registered event (problem, requirement change, etc.). 14

18. Definitions • Configuration control board (CCB). Person or a group of persons assigned responsibility and authority to make decisions on the configuration. (Also called Change Control Board) • Impact analysis. The assessment of the impact of a requested requirements change to the layers of documentation and components. 15 16

20. Software is Complex • Firefox is 12,625,661 LOC • Eclipse Luna 10 Million LOC more than pervious version ?? • Office 2013, 40+ Million LOC

21. Software Changes • New versions of software systems are created as they change (new features, bugs fixed, etc.) • New versions are created for new platforms. • Older versions may continue along with newer versions.

22. Software Families

23. How do developers work? • List of remaining features/bugs. • Copy for each person. • Working in parallel (even on same file). • Submit their changes. • Reviews by others. • Merge and resolve conflicts. • History and reverting when needed.

24. What problems may occur? • Who changed this? • This bug was not there ! • My changes are now lost ! • I worked on a separate copy, how to I merge with the main code?

25. 2. Version Control Systems • VCS is a repository of files. • Every change made to the source is tracked, along with who made the change. • Keeps track of your versions and changes: • ○ When? • ○ Who? • ○ What did you change? • ○ Why?

26. Why Version Control System? • Reversion: If you make a change, and discover it is not viable, how can you revert to a code version that is known to be good? • Change/Bug Tracking. • Branches: How to introduce a completely new feature or concept and not mess up the working code? • Merging branches: If I divided the code, how to merge new code with good old code and not mess up.

27. Popular VCS

28. 1.2 :Revision 1.3 :Revision 1.4 :Revision 1.3.1.2:Revision 1.3.1.1:Revision 1.3.2.1:Revision Multiple Versions May be Maintained 1.1 :Revision Branch 1.3.1 Branch 1.3.2

29. How to Name/Number Versions?

30. How to Number Versions • Many ways ! • Externally, • Major.Minor.Revision (Bug Fix) • In House • Same as above with build number • Major.Minor.Revision.Build • Or Year.Month.Day.Build

31. How to Number Versions • More Complex Scheme: • major.minor.milestone.revision-build • major: significant architectural changes or important advancements in capabilities. • minor: Small changes and new features that does not require architectural changes. • milestone: Indicates stability and maturity of the code: • 0 for development/pre-alpha • 1 for alpha • 2 for beta • 3 for release candidate (RC) • 4 for final/production release • revision: Indicates release, patch or bug fix number. • Build: Unique references to specific builds, typically incremented at each build.

32. How to Number Versions • 1.4.2.0-798: • First beta release of version 1.4, created by build number 798. • 1.9.4.0-986: • First production release of version 1.9, created by build number 986. • 1.9.4.2-990: • Second bug fix release of version 1.9, created by build number 990.

34. 3. Change Control • Changes are inevitable • Who can request changes ? • Who should approve them ? • How can we evaluate the impact and cost of a change ? • What process to follow ?

35. Change Request • A change request (CR) is a request to expand or reduce the project scope; modify policies, processes, plans, or procedures; modify costs or budgets; or revise schedules • CR be originated by anyone at any point in the software life cycle.

36. Change Types • Bug fixing (corrective action) • Adding features • Simplifying code • Changing schedule • …..

37. Change Control Process

38. Bug Tracking Systems

39. Change Management Systems

41. 4. Backup Plan • Many things can happen to your digital data and files. • disk failure • virus • intentional damage • human mistakes • natural disasters • Many things can happen to your digital data and files.

42. What to Backup • Source code • Resource files • Configuration data • Documents • Tools ?

43. When and Where to Backup • On-site • Off-site • Storage services • Daily, weekly, monthly ? • Do a mockup

45. 5. Release Management • Three companies decide independently to develop appointment scheduling software. They all have the knowledge and funding to create a good product. • Company A releases on time with 100 known issues and is a success. • Company B releases on time with 50 known issues and fails. • Company C releases late with 10 known issues but fails because Company A had already captured the market.

46. Definition of Management • The process by which a product is made ready for distribution to customers. Release management is the coordination of all the activities leading to and including product release to customers. • The purpose of release management is to ensure products are ready when promised.

47. What is a Release ? • Delivery of a “system” from a supplier (development house) to a customer. • The “system” consists of a set of authorized and integratedcomponents. • The customer is the internal or external recipient of the system

48. Components of a Release? • Golden Build (software): CD-ROM, files • Documentation and Help • Training materials • Internal documents • Release Notes • http://en.wikipedia.org/wiki/Software_release_life_cycle

49. Types of Releasesin terms of maturity • Alpha • Tester test the product. • Can be unstable, crash or cause data loss. • Usually kept internal. • Beta • SW is feature complete • Customers / users test the software • Early access • Closed / open beta release • Production or live release

50. Types of Releasesin terms of content / purpose • Major = significant new features, product launch, planned, pull, ~annual • Minor = small new features, backwards compatible, planned, pull, ~semi-annual • Patch = collection of bug fixes, planned, pull, ~quarterly • Emergency = Urgent bug fix, harmful if not fixed, unplanned, push, as needed