4. History
1980, Bersoff, E. H., Henderson, V.D., and
Siegel, S. G. Software Configuration
Management. Prentice-Hall.
1984, The British Standard BS 6488
1987, IEEE Guide to Software Configuration
Management 1987. IEEE/ANSI Standard
1042-1987.
1987, U. S. Department of Defense. DoD
2167a Standard 1987. DoD.
5. Why SCM is needed
The project body
The project may be big. When a change is made in a shared
component, the user may not be notified. (The change may be a bug
fix or an improvement.)
The time
The development progress steps may last long. When the versions
become a tree, the bugs could appear or disappear in different nodes.
The people
A lot of people may be involved. A simultaneous update may destroy
the others’ work.
6. The goal (why)
To have change activity converge
Controlling ad-hoc change creates a stable
software development environment
Control of change is a major part of baseline
management
SCM co-ordinates access to change of the
software work products which is particularly
important when there is more than one
individual work on a software work product
7. Concept
“Configuration management involves the collection
and maintenance of data concerning the hardware
and software of computer systems that are being
used.” [SIMON & DENNIS - Ref 1]
“CM embodies a set of techniques used to help
define, communicate and control the evolution of a
product or system through its concept, development,
implementation and maintenance
phases.” [SWEETMAN - Ref 2]
“CM, a key concept in the Information Age, is a set of
systematic controls to keep information up to date
and accurate.” [MORRIS - Ref 3]
8. Concept (cont’d)
“A discipline applying technical and
administrative direction and surveillance
to. …” (IEEE)
“A collection of hardware, software,
and/or firmware, which satisfies an end-
use function and is designated for
configuration management.quot; (ISO)
9. What is not
Just version management
Just change management
Just a build-and-release tool
An administration tool
11. Principles of SCM
Configuration Identification
– Baselines
Change Control
Configuration Status Accounting
Configuration Audits and Reviews
– SCM metrics
12. Configuration Identification
SCM Planning document
– Objectives, responsibilities, and methods
Identify configuration items:
– Independent components of the system
Logical configuration hierarchy
– Object-based view
– Directory-based view
13. Baselines
Complete status of a CI at a given time
Know quality and functionality
Unchangeable and able to recreate
Mozilla SCM Roadmap
14. Change Control
Control change between baselines
Various levels of control
– Open policy (no control, just tracking)
– Informal code review by module owner
– Change Control Board (CCB)
Tailor level to organization and project
15. Configuration Status
Accounting
Monitor status of CIs and change
requests
– Complete listing of all changes since last baseline
(including who, what, when)
– Ideally changes should be traceable to rationale
Allows tracking of progress to next
baseline
Allows for previous releases/versions to
be extracted for testing
16. Configuration Audits
and Reviews
Validation of completeness and consistency
SCM audits occur during project transitions
– Requirements, design, implementation, test, …
Ensures that SCM plan is being followed
Useful to review SCM metrics gathered
Feedback allows process improvement
17. Implementation Issues
Requires champions, sponsors, agents
Requires planning (SCMP)
Requires training and documentation
Requires maintenance
Can be measured and improved
18. SCM Automation
Why Automation?
- Difficult to manage developments
by large teams operating at different
remote sites
- Projects are becoming bigger and more
complex
20. SCM Automation (cont’d)
Components Concepts
- Component concepts help identify and access
components of a software product.
- Requirements covered: version control,
configuration, repository, etc.
- Example of tools or systems: Revision Control
System (RCS), Sherpa Design Management
System (DMS)
21. SCM Automation (cont’d)
Structure and Construction Concepts
- Concepts that deal with capturing changes to
a component and its structure.
- Requirements covered: building, optimizing ,
recording information to allow regeneration of
components, etc.
- Example of tools or systems: Aide-De-Camp
(ADC), Jasmine system model, Rational…
22. SCM Automation (cont’d)
Team Concepts
- Concepts that help with the co-ordination and
synchronization of software engineering
teams working on a project.
- Requirements covered: work areas for
isolating work, synchronizing, concurrent
work…
- Example of tools or systems : Shape,
Software Management System (SMS),
Network Software Environment (NSE)
23. SCM Automation (cont’d)
Process Concepts
- Concepts that are related to process
functionalities.
- Requirements covered: lifecycle support, task
management, communication and
automatically recording information.
- Example of tools or systems : PowerFrame,
ISTAR, LIFESPAN, Change and Configuration
Control (CCC)
24. Tool Class 1
Code or Developer oriented CM tools only
supply the code management, version
control, including check-in, check-out,
merge, etc.
25. Tool Class 2
Process oriented CM tools also supply management
for software development activities. It may cover:
Version Control
Change Control
Product Management
Problem Tracking
Activity Tracking
Build Management
Document Management
Requirements Tracking.
27. SCM Challenges (cont’d)
• Technological Issues
- Switching CM Capabilities
- Interoperability between CM
- Global Perspective on CM
- Repositories
- Distributed CM
- Perfective Maintenance Support
37. References
A. Brown, S. Dart, P. Feiler, K. Wallnau. The State of Automated Configuration
Management, Software Engineering Institute. Carnegie Mellon University. 1991.
http://www.sei.cmu.edu/legacy/scm/abstracts/absatr_cm_state.html
Berlack, R.H. Evaluation & Selection of Automated Configuration Management
Tools. 1995. http://www.stsc.hill.af.mil/crosstalk/1995/nov/evaluati.asp
Dart, Susan. Concepts in Configuration Management. Software Engineering Institute.
Carnegie Mellon University. 1991. http://www.sei.cmu.edu/legacy/scm/abstracts/
abscm_concepts.html
Eich, Brendan. Mozilla Tree Management Roadmap. Mozilla Organization. 2002. http://
www.mozilla.org/roadmap.html
Humphrey, Watts S. Managing the Software Process. Addison-Wesley Publishing
Company. Reading, Massachusetts. 1990
Kelly, Marion. Configuration Management: The Changing Image McGraw-Hill U.K.,
1996.
Menks, D. Software Configuration Management. University Of Calgary. 2001.
http://www.ucalgary.ca/~dbmenks/seng/seng621/scm.html
Editor's Notes
Hi everyone, Today’s topic is configuration management (CM).
I will introduce the concept of CM.
And Guy will open the door for Basic principles.
Then Stephane will lead us to SCM automation and SCM tools, and also talk about the SCM future
If we have time, I’ll compare the
Before we give the accurate definition of Configuration Management, I’d like to have one simple sentence to show what is the CM, so everybody can have the starting point.
Configuration Management is a documentation system for tracking the work.
Is that simple?
The simplest CM could be a piece of paper. I can use it write down what is the problem, where I find the bug, what I’ve changed to fix the bug. That is what I do everyday.
Well, somebody keep it in mind, but the information can not be shared, it could be forgotten, we say this (head) is not a CM.
How long have the engineers write the memo on a piece of paper?
I tried to dig out the history of formal CM concept. The earliest one I got is 1984 British Standard. I’m pretty sure it is not the earliest one.
My parent worked on computer science in 1958, I’ve pretty sure somebody has invented paper at that time so they can use.
Today, story is different.
The computer has been changed. The computer project has been changed. The expectation has been changed as well.
We have much bigger project. The size is bigger means more components and more shared component. When the shared component is changed, then it’s may not be a simple story on the paper anymore. We may need to notify all the shared users.
The another difference is the development of the project may last longer. We have different releases, we customize the project for different customer. The binder get thicker and thicker and we get harder to find the original paper.
We have much more people involved in the project. When multiple people work in some component simultaneously, it always has problem to overwrite each other’s.
So what we want?
A fantastic(expensive) CM system is not our goal. It is just a tool. We want the tool to help us to have our change activity converge, so we can have a stable product to deliver.
Now, let’s go back to the so called accurate concept of CM.
It is just the memo of work.
The IEEE definition is very interesting. It has 3 key words:
Technical, administrative, and surveillance.
It tends to fit the CM concept to the organization. It is not just a technical issue, it also help the administrator to understand the scope of the target, the problem and current status. And it also supply a evaluation framework to check the work.
From the definition, everybody have the idea in mind. Before we move forvord, I want to emphesize that CM is not:
The CM covers:
Mention that each component builds somewhat upon the next. The last item is optional and the overall process should be tailored for the specific organization.
Configuration Item definition:
Any part of the development and/or deliverable system (whether software, hardware, firmware, drawings, inventories and/or documentation) which needs to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained. CIs can differ widely in complexity and may contain other CIs in a hierarchy. [Kelly, 1996]
1. Known Functionality: The features and functions of a particular baseline will be documented and available for reference.
2.Known Quality: The quality of a baseline will be well defined. For example, all known bugs will be documented and the software will have undergone a complete set of testing before being released.
3.Unchangable: A baseline, once defined, cannot be changed. The list of the CIs and their versions are set in stone. Any changes may become a new baseline, but the existing baseline does not change.
4.Recreatable: All the CIs comprising the baseline can be recreated at any point in time. This is critical for maintaining development, testing, and multiple release versions.
An example baseline for a software configuration item may include the current level of: [Humphrey, 1990]
*Each module including source code.
*Each test case including source code.
*Each build tool used including the compiler.
*Each data set including both test and operational data.
*Each macro, library, and API (header files).
*Each instalation or operating procedure.
Information considered by the Change Control Board
* Size: typically in lines of code (LOC).
*Alternatives: consideration of other approaches to problem.
*Complexity: will the change affect many modules?
*Schedule: affect on other jobs
*Impact: future considerations on design
*Cost: weigh potential costs versus savings.
*Severity: importance of making the change.
*Relation to other changes: synergies or conflicts
*Test: any special test requirements
*Resources: are people available to do work?
*System impact: will this affect performance characteristics?
*Benefits: special reasons to make this change?
*Politics: accommodation of an important user?
*Change maturity: length of time this change has been under consideration.
The following information is required to accurately account for a configuration item's status: [Humphrey, 1990]
*The time at which the baseline was established.
*The time at which each CI and change was included in the baseline.
*A description of each CI.
*The current status of each software-related engineering change.
*The description of each software change.
*The status of each software change.
*The documentation status for each baseline.
*The changes planned for each identified future baseline.
Possible Change Metrics
- Change frequency: indicates error-prone modules
- Total number of changes completed
- Average change completion time
- Number of outstanding changes (per module)
Also mention that these SCM metrics are also used by size and cost estimators.
SCM is common to all process change in that it requires:
Champions: initiate change process and bring it to the attention of management.
Sponsors: senior management must provide support and resources
Agents: responsible for actually planning and implementing the change
SCMP: outlines objectives, responsibilities, and the approach and methods to be used
Outline in brief CVS at Pason:
Requirements and planning doc (cross-platform)
System configuration
How-to docs and FAQ-o-matic
Sysadmin and backup
FtpVC is a very simple shareware, which only support checkin/checkout using FTP. It does not have version label and version branch.
Stephane talked one of the challenge is to transfer the CM data between the different CM system.
StarTeam does very well here. StarTeam can exchange the data with other CM tool (PVCS, SourceSafe)
StarTeam also can export the data to Microsoft Project, so it helps the project planning part of Software Engineering.
Visual Source Safe can integrate with Visual Studio. So the files can be checkin/checkout from Visual Studio