A Brief Introduction to Configuration Management

1
A Brief Introduction to Configuration Management
2
Maintenance is Inevitable

• System requirements are likely to change while
  the system is being developed because their
  environment is changing
• Systems are tightly coupled to their environment
• When a system is installed it changes the
  environment and that can change the system
  requirements
• The delivered system may not meet its
  requirements
• Systems must be maintained to remain useful in
  their environment

3
Types of Maintenance

• Corrective Maintenance (21)
• making changes to repair defects
• Adaptive Maintenance (25)
• making changes to adapt software to external
  environment changes (hardware, business rules,
  OS, etc.)
• Perfective Maintenance (50)
• extending system beyond its original functional
  requirements
• Preventative Maintenance (4)
• modifying work products so that they are more
  easily corrected, adapted, or enhanced

4
Spiral Maintenance Model
5
Maintenance Costs

• Usually greater than the development costs (2 to
  10 times as much in some cases)
• Affected by both technical and non-technical
  factors
• Increase as software is maintained and system
  corruption is introduced
• Aging software can have high support costs (e.g.
  old languages, compilers, etc.)

6
Maintenance Developer Tasks

• Understand system.
• Locate information in documentation.
• Keep system documentation up to date.
• Extend existing functions.
• Add new functions.
• Find sources of errors.
• Correct system errors.
• Answer operations questions.
• Restructure design and code.
• Delete obsolete design and code.
• Manage changes.

7
Maintenance can be tough

• Limited understanding of hardware and software
  (maintainer).
• Management priorities (maintenance may be low
  priority).
• Technical problems.
• Testing difficulties (finding problems).
• Morale problems (maintenance is boring).
• Compromise (decision making problems).

8
Maintenance Cost Factors

• Staff turnover
• no turnover usually means lower maintenance costs
• Contractual responsibility
• developers may have no contractual obligation to
  maintain the delivered system and no incentive to
  design for future change
• Staff skills
• maintenance staff are often inexperienced and
  have limited domain knowledge
• Program age and structure
• as programs age their structure deteriorates,
  they become harder to understand and change

9
Maintenance Prediction

• Concerned with determining which parts of the
  system may cause problems and have high
  maintenance costs
• Change acceptance depends on the maintainability
  of the components affected by the change
• Implementing changes degrade system and reduces
  its maintainability
• Maintenance costs depends on number of changes
• Costs of change depend on maintainability

10
Maintenance Prediction
11
Maintenance Complexity Metrics

• Predictions of maintainability can be made by
  assessing component complexities
• Most maintenance efforts only affect a small
  number of system components
• Maintenance complexity depends on
• complexity of control structures
• complexity of data structures
• module size

12
Maintenance Process Metrics

• Maintainability measurements
• number of requests for corrective maintenance
• average time required for impact analysis
• average time to implement a change request
• number of outstanding change requests
• If any if these increases it may signal a decline
  in maintainability

13
Maintenance Tools

• Text editors (better than punch cards).
• File comparison tools.
• Compilers and linkage editors.
• Debugging tools.
• Cross reference generators.
• Complexity calculators.
• Control Libraries.
• Full life cycle CASE tools.

14
Configuration Management

• Software changes are inevitable
• One goal of software engineering is to improve
  how easy it is to change software
• Configuration management is all about change
  control.
• Every software engineer has to be concerned with
  how changes made to work products are tracked and
  propagated throughout a project.
• To ensure quality is maintained the change
  process must be audited.

15
Software Configuration Items

• Computer programs
• source
• executable
• Documentation
• technical
• user
• Data
• contained within the program
• external data (e.g. files and databases)

16
Baselines

• A work product becomes a baseline only after it
  is reviewed and approved.
• A baseline is a milestone in software development
  marked by the delivery of one or more
  configuration items.
• Once a baseline is established each change
  request must be evaluated and verified before it
  is processed.

17
Sources of Change

• New market conditions dictate changes to product
  requirements or business rules
• New customer needs demand modification of data,
  functionality, or services
• Business reorganization causes changes in project
  priorities or SE team structure
• Budgetary or scheduling constraints require
  system to be redefined

18
Change Requests

• Requests can come from users, customers, or
  management
• Change requests should be carefully analyzed as
  part of the maintenance process before they are
  implemented
• Some changes requests must be implemented
  urgently due to their nature
• fault repair
• system environment changes
• urgently required business changes

19
Change Prediction

• Predicting the number of changes requires
  understanding the relationships between a system
  and its environment
• Tightly coupled systems require changes whenever
  the environment changes
• Factors influencing the system/environment
  relationship
• number and complexity of system interfaces
• number and volatility of system requirements
• business processes where the system is uses

20
Soo! What is Configuration Management?

• SCM is the control of the evolution of complex
  systems,, for the purpose to contribute to
  satisfying quality and delay constraints.
• Jacky Estublier
• SCM provides the capabilities of identification,
  control, status accounting, audit and review,
  manufacture, process management, and teamwork.
• Susan Dart

21
What is CM (cont.)

• CM is a key process in Capability Maturity Model
  (recently updated to CMMI)
• Level 1-Initial ad hoc/chaotic
• Level 2-Repeatable basic project management and
  documentation
• Level 3-Defined standard and complete process
  control and procedures
• Level 4-Managed predictable process performance
  and precise measurements
• Level 5-Optimizing continuous and recursive
  improvement to performance
• CM operates through the software life cycle

22
What is CM not

• Not just version control
• Not just for source code management
• Not only for development phase
• Selecting and using tools are important, but
  design and management of CM process are more
  crucial for project success

23
Some Simple CM Scenarios

• Developer A wants to see latest version of foo.c
  and its change history since last week
• B needs to revert foo-design.doc to its version
  two days ago
• B makes a release of the project and he needs to
  know what items to include and which version

24
Some Simple CM Scenarios (cont.)

• A lives in New Dehli, India and B lives in
  Boston, US, they want to work on HelloWorld.java
  together
• In the latest release, a serious bug is found and
  manager C wants to track what changes caused the
  bug, who made those changes and when
• C wants to get reports about current project
  progress to decide if she needs to hire more
  programmers and delay the alpha release

25
SCM Terminology

• Configuration Item (CI)
• Version, Variant, and Revision
• Configuration
• Baseline
• Workspace

26
Configuration Item (CI)

• An approved and accepted deliverable, changes
  have to be made through formal procedure
• Examples
• Management plan
• Requirement
• Design specification
• Source code and executable code
• Test specification, data, and records
• Log information
• User documentation
• Library and supporting software
• Bug reports, etc.

27
Version, Variant, and Revision

• Version a CI at one point in its development,
  includes revision and variant
• Revision a CI linked to another via revision-of
  relationship, and ordered in time
• Variant functionally equivalent versions, but
  designed for different settings, e.g. hardware
  and software
• Branch a sequence of versions in the time line

Win32 on x86
1.3.1.1
1.3.1.2
Solaris on SPARC
28
How Versions are Stored

• Full copy of each version
• Delta (differences between two versions)
• Forward delta
• Reverse delta
• Mixed delta

1.2
1.3
1.4
1.1
1.2
1.3
29
Configuration

• An arrangement of functional CIs according to
  their nature, version and other characteristics
• Guaranteed to recreate configurations with
  quality and functional assurance
• Sometimes, configuration needs to record
  environment details, e.g. compiler version,
  library version, hardware platform, etc.
• Simple examples
• Ant buildfile, Makefile

30
Baseline

• A collection of item versions that have been
  formally reviewed and agreed on, a version of
  configuration
• Marks milestones and serves as basis for further
  development
• Can only be changed via formal change management
  process
• Baseline change sets to create new baselines

31
Workspace

• An isolated environment where a developer can
  work (edit, change, compile, test) without
  interfering other developers
• Examples
• Local directory under version control
• Private workspace on the server
• Common Operations
• Import put resources into version control in
  repository
• Update get latest version on the default branch
• Checkout get a version into workspace
• Checkin commit changes to the repository

32
Version Control Models (1/3)

• Basic problem of collaborative work

Figure from svn-book
33
Version Control Models (2/3)

• Model 1-Pessimistic lock-modify-unlock

• Problems
• Forget to unlock
• Parallel work not possible
• Deadlock

Figure from svn-book
34
Version Control Models (3/3)

• Model 2-Optimistic copy-modify-merge

Figure from svn-book
35
SCM Processes

• Change control process
• Status accounting
• Configuration audit
• Release management
• CM planning

36
Change Control Process

• Submission of Change Request (CR)
• Technical and business evaluation and impact
  analysis
• Approval by Change Control Board (CCB)
• Engineering Change Order (ECO) is generated
  stating
• changes to be made
• criteria for reviewing the changed CI
• CIs checked out
• Changes made and reviewed
• CIs checked in

37
Status Accounting

• Administrative tracking and reporting of CIs in
  CM system
• Examples
• Status of proposed changes
• Status of approved changes
• Progress of current version, on or behind
  schedule
• Estimate of resources to finish one task
• bugs identified by configuration audit

38
Configuration Audit

• Independent review or examination to assess if a
  product or process is in compliance with
  specification, standards, contractual agreement,
  or other criteria
• Examples
• Verifies that CIs are tested to satisfy
  functional requirements
• Verifies that baseline contains necessary and
  correct CI versions
• Ensures that changes made to a baseline comply
  with the configuration status reports

39
Release Management

• Creation and availability of a new version of
  software to the public
• Release format
• Source code build script instructions
• Executables packaged for specific platforms
• Other portable formats Java Web Start, plugins
• Patches and updates automatic, manual
• Release content
• Source and/or binary, data files, installation
  scripts, libraries, user and/or developer
  documentation, feedback programs, etc.

40
Make a CM Plan

• Standards
• IEEE Std 828 (SCM Plans), ANSI-IEEE Std 1042
  (SCM), etc.
• CM plan components
• What will be managed (list and organize CIs)
• Who will be responsible for what activities
  (roles and tasks)
• How to make it happen (design processes for
  change requests, task dispatching, monitoring,
  testing, release, etc.)
• What records to keep (logs, notes,
  configurations, changes, etc.)
• What resources and how many (tools, money,
  manpower, etc.)
• What metrics to measure progress and success

41
CM Tools

• Version control
• RCS, CVS, Subversion, Visual Source Safe,
  Rational ClearCase
• Bug tracking
• Bugzilla, Mantis Bugtracker, Rational ClearQuest
• Build
• GNU Make and many variants, Ant
• Project management
• Sourceforge.net, freshmeat.net, GForge, DForge

42
Reference and Further Reading

• Reference
• Introduction to Configuration Management, lecture
  slides for COMP3100/3500, Ian Barnes, the
  Australian National University.
• Software Configuration Management, Center for
  Development of Advanced Computing, Mumbai at
  Juhu, India.
• Concepts in Configuration Management Systems,
  Susan Dart, CMU.
• Software Configuration Management A Roadmap,
  Jacky Estublier, CNRS, France.

• Further Reading
• Software Engineering, a Practitioners Approach
  (6th), part 4, Roger Pressman.
• Code Complete (2nd), Steve McConnel.
• http//cmcrossroads.com/
• Implementing and Integrating PDM and SCM, Ivica
  Crnkovic et al.
• Version Control with Subversion, Ben
  Collins-Sussman et al.

43
Configuration Management Tasks

• Identification
• tracking changes to multiple SCI versions
• Version control
• controlling changes before and after customer
  release
• Change control
• authority to approve and prioritize changes
• Configuration auditing
• ensure changes are made properly
• Reporting
• tell others about changes made

44
Version Control Terms

• Entity
• composed of objects at the same revision level
• Variant
• a different set of objects at the same revision
  level and coexists with other variants
• New version
• defined when major changes have been made to one
  or more objects

45
Change Control Process - 1

• Change request is submitted and evaluated to
  assess its technical merit and impact on the
  other configuration objects and budget
• Change report containing the results of the
  evaluation is generated
• Change control authority (CCA) makes the final
  decision on the status and priority of the
  change based on the change report

46
Change Control Process - 2

• Engineering change order (ECO) is generated for
  each change approved
• ECO describes the change, lists the constraints,
  and criteria for review and audit
• Object to be changed is checked-out of the
  project database subject to access control
  parameters for the object
• Modified object is subjected to appropriate SQA
  and testing procedures

47
Change Control Process - 3

• Modified object is checked-in to the project
  database and version control mechanisms are used
  to create the next version of the software
• Synchronization control is used to ensure that
  parallel changes made by different people dont
  overwrite one another

48
Configuration Management Team

• Analysts.
• Programmers.
• Program Librarian.

49
Change Control Board

• Customer representatives.
• Some members of the Configuration management
  team.

50
Programmers View - 1

• Problem is discovered.
• Problem is reported to configuration control
  board.
• The board discusses the problem
• is the problem a failure?
• is it an enhancement?
• who should pay for it?
• Assign the problem a priority or severity level,
  and assign staff to fix it.

51
Programmers View - 2

• Programmer or analyst
• locates the source of the problem
• determines what is needed to fix it
• Programmer works with the librarian to control
  the installation of the changes in the
  operational system and the documentation.
• Programmer files a change report documenting all
  changes made.

52
Change Control Issues

• Synchronization (when?)
• Identification (who?)
• Naming (what?)
• Authentication (done correctly?)
• Authorization (who O.K.d it?)
• Routing (whos informed?)
• Cancellation (who can stop it?)
• Delegation (responsibility issue)
• Valuation (priority issue)

53
Software Configuration Audit - 1

• Has the change specified by the ECO been made
  without modifications?
• Has an FTR been conducted to assess technical
  correctness?
• Was the software process followed and software
  engineering standards applied?

54
Software Configuration Audit - 2

• Do the attributes of the configuration object
  reflect the change?
• Have the SCM standards for recording and
  reporting the change been followed?
• Were all related SCI's properly updated?

55
Configuration Status Report

• What happened?
• Who did it?
• When did it happen?
• What else will be affected by the change?