CS 425/625 Software Engineering Software Configuration Management

1
CS 425/625 Software Engineering Software
Configuration Management

• Guest Speaker Jim Hunt
• December 3, 2007

2
Outline

• Introduction
• Version Management
• Change Control
• Build Systems
• Status Accounting
• Audit

3
Introduction.

• Software Configuration Management Software CM
  is a discipline for controlling the evolution of
  software systems.... The standard definition for
  CM taken from IEEE standard 729-1983 includes
• Identification an identification scheme is
  needed to reflect the structure of the product.
  This involves identifying the structure and kinds
  of components, making them unique and accessible
  in some form by giving each component a name, a
  version identification, and a configuration
  identification. For example, this addresses the
  question, "What version of the file is this?"
• Control controlling the release of a product and
  changes to it throughout the lifecycle by having
  controls in place that ensure consistent software
  via the creation of a baseline product. For
  example, this addresses the question, "How many
  changes went into the latest version of this
  product?"
• Status Accounting recording and reporting the
  status of components and change requests, and
  gathering vital statistics about components in
  the product. For example, this addresses the
  question, "How many files were affected by fixing
  this one bug?"
• Audit and review validating the completeness of
  a product and maintaining consistency among the
  components by ensuring that components are in an
  appropriate state throughout the entire project
  life cycle and that the product is a well-defined
  collection of components. For example, this
  addresses the question, "Are all the correct
  versions of files used in this current release?"

4
.Introduction

• Software The components that comprise a
  software system. These configuration items
  include, but are not limited to
• Requirements and specifications
• Source code
• Structured environment (links)
• Development tools
• Resource files (graphics, sounds, etc.)
• Test plans
• User documentation
• Executable or binary output

5
..Introduction..

• Configuration An arrangement of functional
  units according to their nature.
• Source
• Libraries
• Tools
• Resources
• Structure
• Release Documentation
• Supporting Documentation

6
Introduction.

• Management Coordinating and harmonizing a group
  toward accomplishing a goal.
• Software Configuration Management is a planned
  activity
• Identify
• Process
• Analyze

Process
Identify
Analyze
7
Version Management..

• Version a set of configuration items each
  identified by a revision.

File 1 Rev 3 Rev 2 Rev 1
File 2 Rev 4 Rev 3 Rev 2 Rev 1
File 3 Rev 1
Version 2
Version 2
Version 1
Version 2
Version 1
8
.Version Management.

• Methods for revision control
• Archive files
• 1 archive contains a base revision and a list of
  differences between revisions
• Works well for text
• Archive contains all the history of the file
• Flat files
• Each revision is a complete copy of the file
  including any differences
• Works well for binary
• Metadata is required to contain the history

9
..Version Management

• Common problems with multiple developer projects
• Simultaneous Update Two or more programmers
  work separately on the same program. Last one to
  change the program can easily overwrite the
  others work.
• Shared Code Each programmer in the team needs
  to know if a piece of the program has been
  modified. Their individual workspaces need to be
  updated to reflect this.
• Common Code In large systems common functions
  and interfaces may change. As this affects the
  design of calling programs, every programmer must
  be alerted.

10
Version Management..

• Techniques used in your Personal Software Process
• Check In / Check Out When ready to edit a file,
  Check Out the latest revision and apply a
  semaphore to indicate to others that they someone
  else is editing. (Lock the file) When finished,
  Check in the new revision and unlock.
• Optimistic lock In this situation, the work
  file is edited and checked in. On Check In
  differences are detected, and a merge is
  requested if necessary.
• Change sets Many times, a changes to software
  requires changes in multiple files. Checking in
  revisions of a single file without the others can
  result in breakage. Being able to identify a set
  of changes and being able to undo the set of
  changes as a whole is advantageous. (Atomic
  Commit)
• Integrate your PSP into a Team Software Process
• Follow team coding standards
• Use Peer to Peer code inspections
• Communicate to the team through project roles
  (Project Manager, Software Architect, Module
  Owner, etc)

11
Change Control..

• Baseline An identified Version of a system to
  which changes are may be applied.
• Change Request A record that describes the
  attributes of a change.
• Description (Bug, Feature, Variant)
• Baseline to be changed ( Found In version)
• Affected Items (BOM)
• Status - lifecycle or workflow state (open,
  estimated, assigned, fixed, base lined, verified,
  closed)
• Release A baseline that has gone through a
  verification process and packaged for downstream
  use.

Baseline2 Baseline1 CR2 CR4
12
.Change Control..

• Understand the impact of Change
• Upstream impact - How does the requested change
  affect the requirements, architecture and
  specifications.
• Value Analysis What is the cost of
  implementation vs. the added value of the change.
  
• Downstream impact What changes in build
  scripts, test plans, user documentation, and
  setup are necessary to implement the change.
• Change is easy risk analysis is hard
• 1990 ATT lost 75 million calls in one incident
  as a result of a single line of code in an code
  upgrade of one of their switches
• Feb 2000 Ferrari 360 Modena recalled for
  anti-lock brake instability Software. April
  2001 recalled again Software.

13
Build systems

• A build system automates the transition from
  source to executable
• Makefiles use rules to invoke commands
  consistently by file type. (i.e. .cpp to .o may
  use a dependency checker, and a compiler to make
  the target .o from the source .cpp)
• Build scripts perform a repeatable build from a
  baseline and changes. Creates a new baseline.
  Performs the compiles, links, and packaging of
  final targets.
• IDE build Simple graphical changes or changes
  to properties can have a big impact as to how the
  product is generated in an integrated development
  environment. The environment itself is a
  candidate for change and version control.

Binary reproducibility is a requirement in
certain regulated business environments such as
Medical Devices and Gaming Machines. Binary
reproducibility means that the executable
software can be recreated identically byte for
byte from the source code at any time by a third
party. Create a thought experiment as to the
steps and deliverable components necessary to
achieve this. Try it.
14
Status Accounting

• A visualization of managed versions and changes
  at the present time
• Shows the identified baseline of components and
  structure
• Shows the identified changes and their respective
  lifecycle disposition
• Used to communicate to the development and
  management teams
• Used as a tool for resource management

Release Dashboard 12/3/2007 Release Dashboard 12/3/2007 Release Dashboard 12/3/2007
Version 1.0 1.1 1.2 1.3 2.0
Status Retired Released In Test In Development In Development
Changes Initial baseline CR1 CR2 CR3 CR4 CR5 FR1 FR2 FR3
Risks Failed - still finding this release in the field Currently supported. Must work around CR3-5 Requires full regression due to Risk of CR3 CR5 makes a change in requirements and specifications, customer buyoff required Project management wants to roll CR4 and CR5 into a single release along with the new features.
15
Audit

• Logs the history of all actions associated with
  the SCM function
• Who
• What
• When
• How
• Used for process improvement
• Used to show liability
• Data may be subject to subpoena

16
Future of SCM

• Case Tools output a great deal of change with
  very little input.
• UML integration with SCM tools
• Tools should be optimized to isolate changes
• Distributed SCM architecture.
• The repository is not in a common location,
  rather the various working locations contain the
  historic revisions.
• Adaptive systems
• Changes are performed by the system itself.
• How can these changes be managed?
• Changes are treated as a data model.
• The program becomes content.
• How does risk get reduced?