scm a la carte c-spin 03/01/2006 ross fraser. agenda ieee/dod standard definition of scm...
TRANSCRIPT
SCM a la Carte
C-SPIN03/01/2006Ross Fraser
AGENDA
IEEE/DoD Standard Definition of SCM Introduction to Pattern Languages SCM Pattern Language
IEEE/DoD StandardDefinition
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project’s software life cycle.
(Configuration Management Principles and Practice, Anne Mette Jonassen Hass)
IEEE/DoD StandardActivities
Configuration Identification Configuration Change Control Configuration Status Accounting Configuration Audits
A New Definition
SCM is a formal process which serves to prevent or mitigate anticipated failures of communication, coordination or control (C3).
SCM is appropriate when impediments to the success of informal methods are present.
Background to pattern languages
1975-1979: Christopher Alexander 1987: Cunningham and Beck 1994: First Pattern Languages of
Program Design (PLoP) conference 1995: “Gang of Four” 1999: Brown, McCormick and
Thomas 2003: Berczuk and Appleton
What is a pattern?
A pattern is a solution to a problem in a context.
A pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces.
What is a pattern language?
A pattern language is a group of patterns in relation to each other.
A pattern language can contain patterns at different levels of applicability
What are the advantages? A pattern is named. A pattern addresses a problem. A pattern works within a context. A pattern is reusable. Patterns fit together into a pattern
language. A pattern can be large or small in scope. A pattern language is extendable.
SCM Pattern LanguageStructure
Domains Procedures Components
SCM Pattern LanguageDomains
Delivery
Inventory
Agreements
Customers
Developers
Users
Examples of “Agreements” Problems
Uncontrolled increase in scope (“feature creep”)
Uncommunicated changes to requirements
Unidentified requirements Unimplemented requirements
Examples of “Inventory” Problems
Lost source code modules Unauthorized code changes Changes that “break” existing
code Loss of valid code changes Proliferation of unidentified files
Examples of “Delivery” Problems
Delivery of obsolete software modules
Delivery of incompatible modules Delivery of inadequately tested
software Delivery of unexpected changes
Inventory Procedure #1
DEVSourc
e
QASourc
e
PRODSourc
e
DEVLoad
QALoad
PRODLoad
Inventory Procedure #2
CommonSource
DEVLoad
QALoad
PRODLoad
Private Workspace
Inventory Component: Gatekeeper Use events to trigger automated
QC/SCM actions Automated build Require comments and other meta-data Require link to change request or defect Syntax checking Standards checking Automated smoke test
Can be a component of either procedure
Resources in Print Fletcher Buckley: Implementing
Configuration Management: Hardware, Software, and Firmware
Wayne Babich: Software Configuration Management: Coordination for Team Productivity
Steve Berczuk & Brad Appleton: Software Configuration Management Patterns: Effective Teamwork, Practical Integration
Resources on the Web
http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html (patterns)
http://www.cmcrossroads.com/bradapp/acme/index.html (SCM)
http://www.scmpatterns.com/
Q&A Discussion
The presentation was followed by a ‘workshop’ in which the audience discussed various problems and solutions amongst themselves while the presenter took notes. Here are some of the discussion items.
Q&A DiscussionWho "owns" the SCM process? Various answers were supplied by members of the
audience: a separate SCM group (although they tend to be pre-
occupied with issues of getting the SCM technology to work, and thus neglectful of the underlying process)
operations (after all, they are most immediately impacted by an unsuccessful delivery)
change control board Since we have argued that SCM tries to resolve
communication problems between people, then for each part of the process, the people who are involved in that particular communication step should be allowed to negotiate a process that works for both (or all) of them.
Q&A Discussion
How do you use SCM to manage data?No one had a good answer to this, but we
observed that this can apply to various kinds of data, including control data and test data. It was also noted that a process for controlling data should not only deliver the correct data, it should also protect sensitive data, such as test data copied from production, with social security numbers in it.
Q&A DiscussionOne participant had a suggestion for protecting
against the delivery of incompatible or obsolete code modules. (This especially applies to the inventory process #1, which is vulnerable to losing concurrency between source and object code.) The list of items to promote should not only include names and version numbers, but also size and a generated checksum for each load module that will be constructed from those items. These can be used to verify (with a reasonable degree of certainty) that the production load modules match the load modules which were tested.