1 / 63

CS352 – Software Engineering II Lectures 4: Intro to SCM

This lecture provides an introduction to Software Configuration Management (SCM), covering topics such as version control, change management, backup planning, and release planning. SCM helps maintain the integrity of software by systematically handling changes to project artifacts.

rristau
Download Presentation

CS352 – Software Engineering II Lectures 4: Intro to SCM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS352 – Software Engineering IILectures 4: Intro to SCM Mohammad El-Ramly, PhD http://www.acadox.com/join/VBEPDR

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

  3. Schedule of first 3 Weeks • Software Architecture • REST Architecture • Cloud Computing • Change & Configuration Management • Agile SW Processes

  4. 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. SCM • Also known as software change, configuration 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 • 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 formally reviewed or agreed upon, that thereafter serves as the basis for further development, and that can be changed only through a formal change control process.

  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.

  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.

  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.

  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

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

  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.

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

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

  21. Software Families

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

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

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

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

  26. Popular VCS

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

  28. How to Name/Number Versions?

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

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

  31. How to Number Versions • More Complex Scheme: • 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 bugfix release of version 1.9, created by build number 990.

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

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

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

  35. Change Control Process

  36. Bug Tracking Systems

  37. Bug Tracking Systems

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

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

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

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

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

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

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

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

More Related