1 / 55

CIE 203 Software Engineering Lecture 13: SW Config. Management

CIE 203 Software Engineering Lecture 13: SW Config. Management. Mohammad El-Ramly, PhD 2016 http://www.acadox.com/join/4DMHHB http://www.acadox.com/class/37407. تذكرة. وهو معكم أينما كنتم والله بما تعملون بصير يعلم خائنة الأعين و ما تخفى الصدور. Last Lecture.

amaliad
Télécharger la présentation

CIE 203 Software Engineering Lecture 13: SW Config. Management

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. CIE 203 Software Engineering Lecture 13: SW Config. Management Mohammad El-Ramly, PhD 2016 http://www.acadox.com/join/4DMHHB http://www.acadox.com/class/37407

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

  3. Last Lecture • Update about project phase 2. • Where are we now ? • why modelling software ? • Sequence diagram ? Dynamic View of the System

  4. Lecture 13 Outline • Definition of SCM • Version Control • Change Management • Backup Plan

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

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

  7. Software Families

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

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

  10. Typical Questions • “What is the correct version of the software module that I have to continue its coding?” • “Who can provide me with an accurate copy of last year’s version 4.1 of the TMY system?” • “What version of the design document matches the software version we are currently adapting to a new customer’s requirements?” • “What version of the software system is installedat ABC Industries?” • “What changes have been introduced in the version installed at the ABC?

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

  12. 1. Software Configuration Management (SCM) • Also known as software change, configuration and release management. • This includes two main activities • Change management • Configuration management

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

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

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

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

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

  18. SW Configuration Item

  19. SW Configuration Item

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

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

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

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

  24. Definitions • Release. The formal notification and distribution of an approved version of a hardware/software system. 12

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

  26. 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. 14 15

  27. Review of Definitions Configuration Item 1 SW Version 2 Version Control 4 Baseline 3 Workspace 5 Check out 7 Check in 6 Branch 8 Merging 9 Build 10 Building 11 Release 12 CR 13 CCB 14 Impact Analysis 15

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

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

  30. Popular VCS

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

  32. How to Name/Number Versions?

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

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

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

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

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

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

  39. Change Control Process

  40. Bug Tracking Systems

  41. Change Management Systems

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

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

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

More Related