1. CS427: Software Engineering I
Grigore Rosu

2. Today’s goals Quick Logistics Software Configuration Management Quiz 1
Change control
Quiz 1

3. Course Logistics
Wiki: (videos!)
Piazza:
Compass:
All class-wide announcements through compass or my.cs
MP1 due Wednesday, 23:59; MP2 out today, 23:59
Follow the rules and the format specified on Wiki!
MP1 due Wednesday, but recommended today (easy MP!)
MP2 will be released today and due in one week
Reminder
MPs (30%), final exam (25%), project (40%), quizzes (5%)
Bonus up to 3% for active participation (lectures, Piazza, …)
Lots of “broad but shallow” reading
Read, read, read everything we list on the wiki
Book chapters and papers will be on EXAM

4. Software Configuration Management (SCM)

5. Why SCM Enables project management Basis for change management
Which version of the system is being discussed/approved?
If something goes wrong, whose/what change broke it
Basis for change management
If change is needed, how do you keep track of what needs to be changed and why?
Some projects even have change boards / committees, approving / voting / debating / prioritsing changes

6. SCM SCM Definition, by the Software Engineering Institute (SEI)
Discipline for controlling the evolution of software systems
Four major aspects, among many other:
Change control
Version control
Building
Releasing
Supported by tools
Requires expertise and oversight
More important on large projects

7. SCM SCM Definition, by the Software Engineering Institute (SEI)
Discipline for controlling the evolution of software systems
Four major aspects, among many other:
Change control
Version control
Building
Releasing
Supported by tools
Requires expertise and oversight
More important on large projects

8. SCM
Keep track of how product changes over time and be able to reproduce any version of it
Control how product changes; make sure needed changes have been made and no improper changes have been made
Not only code, but also non-code resources:
“Test suite for version does not work for other versions. It is almost like the test suites for and ”
“Manual for v slightly different than for other versions.”
Bug fixes …
Design changes …
Use cases ...

9. Necessary Activities to Handle Change Request
Suppose we decided to implement a change request…
Has it been implemented fully? (tests, code, manuals, documentation)
What parts of the system were affected by that change?
I look at a program/document
Why is it like this?
When was it written, by whom?
Tracing both ways:
change control +
version control linked through IDs

10. Versions, Branches
release
3.2
3.1
3.3
mainline
branch

11. Branches Traditional advice for old version control
Avoid (long-lived) branches if possible
Modern version control (Git, HG…)
Encourage (use of short-lived) branches
Good reasons to branch
Fixing bugs in customer version
Experimental version
Political fights

12. Bad reasons to branch Support different hardware platform; instead:
Make subclasses
Use conditional compilation
Make portability library
Support different customer; instead:
Separate unchanged code and changed code
Unchanged code goes in a library
Make subclasses / use conditional compilation for changed code

13. SCM according to the SEI
A discipline for controlling the evolution of software systems
Has many aspects
Identification of items under management
Change control / management
Status accounting
Audit and review

14. Identification What are the configuration items (CI)?
That is, “the what” of configuration management?
E.g.: files, documents, requirements, models, plans, whiteboard pictures, phone conversations, meeting / teleconference videos, user stories, tests, etc., etc., etc.
CIs may have types: hardware, software, doc, people, …
How do you name them?
Unique IDs, at a minimum
What is the relationship between CIs?
Versions
Baseline
Release

15. Versions
Each version is a collection of Cis
Each CI is versioned
V3.1
V3.1.1
V3.1.2 V3
V3.2
V3.3.2
V3.3
V3.3.1

16. Baseline
Baseline is a software configuration item that has been reviewed and agreed upon, and that can be changed only through formal change control procedures
Intermediate versions that haven’t been reviewed are CIs but not baselines
Baseline serves as a basis for defining change
This is the central purpose of a baseline
Baselines are often subjected to SCM audits

17. Release
Release is a software configuration item that the developers give to other people
Release should be a baseline

18. Control Who is allowed to read/write configuration items?
How do you know if changes are allowed/correct?

19. Status accounting
Reporting the status of components and change requests
Which components have changed this week?
Which components did Bob change?
Which components have the most changes?
Which change requests are more than a month old and of priority 3 or greater?

20. Audit and review

21. Audit and review How do we know that the build script is OK?
How do we know that only authorized people can change the main, customer-visible interface?
Can we actually run the version from September 8, 2015?
CIs and their versions and changes are critical for audit

22. Change Control Change request Change control authority
New feature
Bug report
Change control authority
Decides which changes should be carried out
Should link code changes to change requests

23. Example: Bugzilla Originally developed for Mozilla
Bugzilla is a database for bugs. It lets people report bugs and assigns these bugs to the appropriate developers. Developers can use Bugzilla to keep a to- do list as well as to prioritize, schedule and track dependencies

24. Bugzilla Each bug report has:
unique ID, name of reporter, description of bug, component, developer, dependency, [attachments]
Status
unconfirmed, new, resolved, verified, closed
Severity
blocker, critical, major, normal, minor, trivial, enhancement

25. Resolving a bug
FIXED: INVALID: not a bug, or not a bug in Mozilla WONTFIX : a bug that will never be fixed LATER: a bug that won’t be fixed now REMIND: maybe now, maybe later DUPLICATE WORKSFORME

26. Topics to Ponder - Class Exercise, Groups of 3 -
What is the dynamics of people using a change control system?
Developers
Testers
Users
Managers
What about security issues in Bugzilla?
5 Minutes

27. To Make SCM Work Requires:
Bureaucracy
Discipline, training
Tools
Version control – git, svn, cvs, …
Change control – bugzilla, mantis, jira, …
Building – mvn, ant, make, …
Releasing – Maven Central and Nexus, …

28. SCM Manager Complex tools need expert to manage them SCM expert will
Maintain tools
Maintain configuration files, make branches
Do the merging
Create policies on version control, change control

29. Alternatives Toolsmith (often project manager) supports SCM tools
Architect defines configuration files
Developers merge their code back into mainline
Managers and technical leads define policies for version control and change control

30. From required reading:
“Software Configuration Management Patterns: Effective Teamwork, Practical Integration”
Steve Berczuk Brad Appleton

31. Various tests Smoke test Unit test Regression test
Ensure that the system still runs after you make a change
Unit test
Ensure that a module is not broken after you make a change
Regression test
Ensure that existing code doesn’t get worse as you make other improvements

32. Developer issues Private Workspace Private System Build
Prevent integration issues from distracting you, and from your changes causing others problems, by developing in a Private Workspace.
Private System Build
Avoid breaking the build by doing a Private System Build before committing changes to the Repository

33. Codeline Policy Active Development Line Release Line Private Versions
Holds bug fixes for a release
Private Versions
Task Branch
Hide a disruptive task from the rest of the team
Release Prep Codeline

34. Summary of SCM Four aspects Supported by tools
Change control
Version control
Building
Releasing
Supported by tools
Requires expertise and oversight
More important on large projects