2. Outline of Lecture
• Purpose of Software Configuration Management (SCM)
• Motivation: Why software configuration management?
• Definition: What is software configuration management?
• Activities and roles in software configuration management
• Some Terminology
• Configuration Item, Baseline, SCM Directory, Version etc.
• Software Configuration Management Activities
• Establish Baselines, Software Configuration Control etc.
• Software Configuration Management Tools
3. Introduction
• Configuration:
• The components that make up a product.
• Example : Car
• Described as the engine, the chassis, the body, the steering system, the breaking system etc
• All components need to be strictly made as per specifications and assembled properly.
• Configuration Item:
• An entity that is designated for configuration management and treated as a single entity
in CM Process Model is called a configuration Item.
• An entity which we think need to be manage.
• For Software
• Code, HLD , SRS, testing specification etc are configuration Items.
.
6. Any change to the configuration items will affect the product and hence
changes to configuration items needs to be controlled and managed.
7. What is Configuration management ?
• Configuration Management is a way to manage the evolving software.
• Describe the way to manage the configuration items and control the changes
to them.
• Configuration management aim is to control the costs and effort involved in
making changes to a system.
8. Why Configuration management ?
• The problem:
• Multiple people have to work on software that is changing
• More than one version of the software has to be supported:
• Released systems
• Custom configured systems (different functionality)
• System(s) under development
• Software must run on different machines and operating systems
• Need for coordination among stakeholders.
• controls the costs involved in making changes to a system.
• If we don’t control change, it control us.
• uncontrolled changes may lead to a well run software project into chaos.
• Important to improve the quality and reduce errors.
9. Who Does SCM?
• SCM can be staffed in several ways:
• A single team performs all software configuration management activities for
the whole organization.
• A separate configuration management team is set up for each project.
• All the software configuration management activities are performed by the
developers themselves.
• Mixture of all of the above
10. How configuration management?
• We manage changes by
• Identifying the configuration items that are likely to change.
• Establishing relationships among them.
• Defining mechanisms for managing different versions of work products.
• Controlling the changes imposed.
• Auditing and reporting on the change made.
11. Configuration Management Activities
• Configuration item identification
• modeling of the system as a set of evolving components
• Promotion management
• the creation of versions for other developers
• Release management
• the creation of versions for the clients and users
• Change management
• the handling, approval and tracking of change requests
• Branch management
• the management of concurrent development efforts
• Variant management
• the management of versions intended to coexist
12. SCM Activities from IEEE std
• Establish baselines
• Assign unique identifier to configuration items
• Create baseline document
• Identify different internal releases.
• Ensure complete, current technical product documentation
• Enforce standards
• Software quality assurance (SQA
• Use SCM to promote each CI from one development phase to another.
• Use SCM to identify customer involvement in internal baselines.
13. Different from Software Support
• Software Support is a set of software engineering activities
that
• occur after software has been delivered to the customer and
put into operation.
• SCM is a set of tracking and control activities that are
initiated when
• a software engineering projects begins and terminate only
when the software is taken out of operation.
14. Terminology
• We will define the following terms:
• Configuration Item
• Baseline and Baseline Documents
• SCM Directories
• Version
15. Configuration Item?
“An aggregation of hardware, software, or both, that is designated for configuration
management and treated as a single entity in the configuration management process.”
An entity that is designated for configuration management and treated as a single entity
in CM Process Model is called a configuration Item.
• Software configuration items are not only program code segments but all type of
documents according to development, e.g
• all type of code files
• drivers for tests
• analysis or design documents
• user or developer manuals
• system configurations (e.g. version of compiler used)
• In some systems, not only software but also hardware configuration items (CPUs,
bus speed frequencies) exist.
• Even a commercial product used in the system can be a configuration item
16. Managing Configuration Items
• Large projects typically produce thousands of entities (files, documents, data ..etc.)
which must be uniquely identified.
• use proper naming conventions
• Any entity managed in the software engineering process can potentially be
brought under configuration management control.
• But not every entity needs to be under configuration management control all the
time.
• Two Issues:
• What: Selection of Configuration Items
• What should be under configuration control?
• When: When do you start to place entities under configuration control?
17. Which of these Entities should be configuration Items?
• Problem Statement
• Software Project Management Plan (SPMP)
• Requirements Analysis Document (RAD)
• System Design Document (SDD)
• Project Agreement
• Object Design Document (ODD)
• Dynamic model, Object model, Functional model
• Unit tests and Integration test strategy
• Source code
• API Specification
• Input data and data bases
• Test plan and test data
• Support software that is part of the final system
• Support software that is not part of the product
• User manual and Administrator manual
19. Version and version control
“The initial release or re-release of a configuration item associated with a complete compilation or
recompilation of the item. “
• Versions may not always be created in sequential order, e.g. we create 1.0 -> 1.1 -> 1.2 -> 2.0 and then we
may need to create 1.3 for some customers who can not run 2.0 but need some changes or improvements.
• With big software, we may e.g have 4.0 as the official current version. we work on 5.0 to release it as the
next official version, but we have already started to create 6.0, as it takes so long to get it ready.
• different versions have different functionality.
20. Baseline and Baseline document
• Baseline:
• A work product that has been formally reviewed and agreed upon that serves as the basis for
further development.
• It can be changed only through formal change control procedures.
• Baseline is a kind of a milestone in software development.
• Baseline document:
• A software document or set of documents that completely describes a configuration item(CI)
21. Examples of Baselines
• Baseline A:
• All the APIs have completely defined and the bodies of the methods are empty.
• Baseline B:
• All data access methods are implemented and tested.
• Baseline C:
• The GUI has implemented.
22. More on baselines
• As systems are developed, a series of baselines is developed, usually after a review
• analysis review, design review, code review, system testing, client acceptance
• Developmental baseline (CIs: RAD, SDD, Integration Test, ...)
• Goal: Coordinate engineering activities
• Functional baseline (CIs: first prototype, alpha release, beta release)
• Goal: Get first customer experiences with functional system
• Product baseline (product)
• Goal: Coordinate sales and customer support
• Many naming scheme for baselines exist (1.0, 3.14159, 6.01a,, ...)
• A 3 digit scheme is quite common: MacOS X 10.3.6
• Release(Customer). Version(Developer). Revision(Developer)
23.
24. Change Management
• Change management is the handling of change requests
• A change request leads to the creation of a new release
• General change process
• The change is requested (this can be done by anyone including users and developers)
• The change request is assessed against project goals
• Following the assessment, the change is accepted or rejected
• If it is accepted, the change is assigned to a developer and implemented
• The implemented change is audited.
• The complexity of the change management process varies with the project.
• Small projects can perform change requests informally and fast while complex projects require detailed change request
forms and the official approval by one more managers.
26. Change policies
• Whenever a promotion or a release is performed, one or more policies apply.
• The purpose of change policies is to guarantee that each version, revision or release
conforms to commonly accepted criteria.
• Examples for 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 persons.”
27. SCM Audit
• The following questions should be answered
• specified changes have made/ not? Have any additional modifications been incorporated?
• Has formal technical review been conducted to assess technical correctness?
• Has the software process been followed and SE standards been applied?
• Has the change been appropriately recorded in the SCIs?
• Have Software Configuration Management procedures for the change been followed?
• Have all related SCIs been properly updated?
28. SCM Directories
• Master Library.. A collection of approved and released code as well as released software documents distributed to a client
or to the marketplace.
• Production Library a collection of software artifacts produced during a project.
• Software development Library a collection of source code(classes,programs.. Produced during a project.
• Software archive a collection of source code and related documents at the close of a project. All released documentation
and software in the master library should be backed up in the software archive
29. SCM Directories
• Programmer’s Directory (IEEE: Dynamic Library)
• Library for holding newly created or modified software entities or artifacts.
• The programmer’s workspace is controlled by the programmer only
• Master Directory (IEEE: Controlled Library)
• Manages the current baseline(s) and for controlling changes made to them.
• Entry is controlled, usually after verification.
• Changes must be authorized.
• Software Repository (IEEE: Static Library)
• Archive for the various baselines released for general use.
• Copies of these baselines may be made available to requesting organizations
31. Creating a Model for SCM
• We just learned that promotions are stored in the master directory and releases are
stored in the repository.
32. • Problem: There can be many promotions and many releases
• Solution: Use Multiplicity
Promotions and Releases are both versions
Solution: Use Inheritance
33. • Problem: A configuration item has many versions
• Solution: Create a 1-many association between Configuration Item and
Version
35. Software configuration management Planning
• Software configuration management planning starts during the early phases of a project.
• The outcome of the SCM planning phase is the Software Configuration Management Plan (SCMP) which
might be extended or revised during the rest of the project.
• The SCMP can either follow a public standard like the IEEE 828, or an internal (e.g. company specific)
standard.
36. The Software Configuration
Management Plan
• Defines the types of documents to be managed and a document naming scheme.
• Defines who takes responsibility for the CM procedures and creation of baselines.
• Defines policies for change control and version management.
• Describes the tools which should be used to assist the CM process and any limitations on their use.
• Defines the configuration management database used to record configuration information.
37. Tools for Software
Configuration Management
• Software configuration management tool make it possible to establish, control, and
maintain repositories of software project documents . There are a number of different
types of software repositories.
• Master Library.. A collection of approved and released code as well as released
software documents distributed to a client or to the marketplace.
• Production Library a collection of software artifacts produced during a project.
• Software development Library a collection of source code(classes,programs.. Produced
during a project.
• Software archive a collection of source code and related documents at the close of a
project. All released documentation and software in the master library should be
backed up in the software archive.
38. Tools for Software
Configuration Management
• Software configuration management is normally supported by tools with different functionality.
• Examples:
• RCS revision control system
• very old but still in use; only version control system
• Automatically adjusts the version number each time a file is extracted for editing.
• CVS (Concurrent Version Control)
• based on RCS, allows concurrent working without locking
• http://www.cvshome.org/
• CVSWeb: Web Frontend to CVS
• Perforce
• Repository server: keeps track of developer’s activities
• http://www.perforce.com
• ClearCase
• Multiple servers, process modeling, policy check mechanisms
• http://www.rational.com/products/clearcase/
