CSSE 375 Software Construction and Evolution:

More SCM, and a loop back to Feathers!

Shawn and Steve

Left – On big systems, SCM is a well-defined process.

2

And – likewise for systems!

3

Recall: Change Management

Change management handles change requests

General Change Process1. Change is requested (this can be done by anyone

including users and developers)

2. Change request is assessed against project goals

3. Change is accepted or rejected

4. If it is accepted, the change is assigned to a developer and implemented (otherwise, it’s returned to originators with rationale)

5. The implemented change is audited

4

Two types of controlling change: Promotion: Internal development state of a software is changed. Release: A changed software system is made visible outside the

development organization.

Approaches for controlling change (Change Policy) Informal (good for research type environments and promotions) Formal (good for externally developed CIs and for releases)

Controlling Changes

UserPromotion

PromotePolicy

Release

ReleasePolicy

SoftwareEngineer

MasterDirectory

Software Repository

Q9

5

Standard SCM Directories

Programmer’s Directory (IEEE Std: “Dynamic Library”) Completely under control of one

programmer

Master Directory (IEEE Std: “Controlled Library”) Central directory of all promotions

Software Repository (IEEE Std: “Static Library”) Externally released baselines

Foo’12 Foo’13

Release

Central sourcecode archive

Promotion

6

Change Policies

When a promotion or a release is performed, one or more policies apply Purpose of policies is to guarantee that each

version, revision, or release conforms to commonly accepted criteria

Example change policies: “No developer is allowed to promote source code

which cannot be compiled without errors and warnings.”

“No baseline can be released without having been beta-tested by at least 500 external users.”

ChangePolicies

7

Recall: Version vs. Revision vs. Release

Version: An initial release or re-release of a configuration

item associated with a complete compilation or recompilation of the item. Different versions have different functionality.

Revision: Change to a version that corrects only errors in

the design/code, but does not affect the documented functionality.

Release: The formal distribution of an approved version.

Question: Is Windows 8 a new version or a new revision compared

to Windows 7?

8

Software Configuration Management Plan Defines the types of artifacts to be managed

and a naming scheme Defines who takes responsibility for the CM

procedures and creation of baselines Defines policies for change control and

version management Describes tools to be used to assist the CM

process and any limitations on their use Defines the configuration management

database used to record configuration information

9

Software Configuration Management Plan

1. Introduction (WHY?)Describes purpose, scope of application, key terms and references

2. Management (WHO?) Identifies the responsibilities and authorities for accomplishing the planned configuration management activities

3. Activities (WHAT?)Identifies the activities to be performed in applying to the project.

4. Schedule (WHEN?) Establishes the sequence and coordination of the SCM activities with project mile stones

5. Resources (HOW?) Identifies tools and techniques required for the implementation of the SCMP

6. MaintenanceIdentifies activities and responsibilities on how the SCMP will be kept current during the life-cycle of the project.

10

Types of Audits In-process Audits

Verify consistency of the design as it evolves through development process

Functional Audits Verify that functionality and performance are

consistent with requirements defined in the SRS Physical Audits

Verify that the as-built version of software and documentation are internally consistent and ready for delivery

Quality System Audits Independent assessment of the compliance to the

software QA plan

11

What is the key tradeoff for making software changes like those in refactoring?

Think for 15 seconds… Turn to a neighbor and discuss

it for a minute Let’s hear what you think…

Q10

12

Paradox of Source Code Change

Code changes can degrade quality (bugs & ill structure), so it is better not to make changes

Not changing code can degrade quality (not fit for purpose), so it is better to change code

To escape this we need confidence in changes How do we know we have it right? How do we know we didn’t break existing

behavior?

Q11

13

Heuristic for Changing Difficult Code Examine code needing change and ask:

What new code will I write? Can I put it in a new method or class? …If so, do it!

Net Gain New responsibilities are separated from old ones Writing a test for a new method or class is often

easier than writing it for an old one

Q12

14

Wait a minute.. Isn’t that bad Advice?

What about putting code where it really belongs?

Answer: When changing difficult code, it

pays to be cautious First task is to make changes

without harming the system Hippocratic oath: “first, do no harm…”

Then the system can be improved

Q13

15

For those Safe (and easy) ChangesBack to Michael Feathers, one more time!

Sprout Method

Sprout Class

Wrap Method

Wrap ClassSprouts are Chia Pet Patterns

Q14