Software Configuration Management Plan of XXX software

Doc # Version: 2013 Page 1 / 7

Thank-you for downloading the

Software Configuration Management Plan
Template!

More templates to download on the:

Templates Repository for Software Development

Process (click here)
Or paste the link below in your browser address bar:
http://blog.cm-dm.com/pages/Software-Development-Process-templates

This work is licensed under the:

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License:
http://creativecommons.org/licenses/by-nc-nd/3.0/fr/

Waiver:
You can freely download and fill the templates of blog.cm-dm.com, to produce technical
documentation. The documents produced by filling the templates are outside the scope of the
license. However, the modification of templates to produce new templates is in the scope of
the license and is not allowed by this license.

To be compliant with the license, I suggest you to keep the following sentence at least
once in the templates you store, or use, or distribute:
This Template is the property of Cyrille Michaud License terms: see http://blog.cm-
dm.com/post/2011/11/04/License

Who am I? See my linkedin profile:

http://fr.linkedin.com/pub/cyrille-michaud/0/75/8b5

You can remove this first page when you’ve read it and acknowledged it!

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Configuration Management Plan of XXX software

Doc # Version: 2013 Page 2 / 7

TABLE OF CONTENTS

1 Identification 3
1.1 Document overview 3
1.2 Abbreviations and Glossary 3
1.2.1 Abbreviations 3
1.2.2 Glossary 3
1.3 References 3
1.3.1 Project References 3
1.3.2 Standard and regulatory References 3
1.4 Conventions 3
2 Organization 3
2.1 Configuration management principles 4
2.2 Configuration management in a development cycle 4
2.3 Configuration management of releases 4
2.4 Configuration management of prototypes 4
2.5 Tasks in development and maintenance 4
2.6 Archiving versions 5
2.7 Link with bugs and features 5
3 Configuration identification 5
3.1 Identification rules of configuration items 5
3.2 Identification rules of SOUPs 6
3.3 Identification rules of installers 6
3.4 Identification rules of archives 6
3.5 Identification rules of documents 6

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Configuration Management Plan of XXX software

Doc # Version: 2013 Page 3 / 7

1 Identification
This document amplifies the “§4 Configuration management” of the Project Management Plan.
If you instantiate this document, leave empty the §4 in the Project Management Plan and add a
reference to this doc.

1.1 Document overview

This document contains the software configuration management plan of software XXX.

1.2 Abbreviations and Glossary

1.2.1 Abbreviations
Add here abbreviations

1.2.2 Glossary
Add here words definitions

1.3 References

1.3.1 Project References

# Document Identifier Document Title

[R1] ID Add your documents references.
One line per document

1.3.2 Standard and regulatory References

# Document Identifier Document Title

[STD1] ID Add your standards references.
One line per document

1.4 Conventions
Typographical convention.
Any other convention.

2 Organization
Describe the organization in which CM resides.
Eg: The SCM support department, shared by all projects of the company, manages software
configuration.
OR

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Configuration Management Plan of XXX software

Doc # Version: 2013 Page 4 / 7

The software configuration is managed by members of the project, with specific tools.
Responsibilities are shared between
 The software configuration manager (SCM),
 The project manager,
 The technical manager.

2.1 Configuration management principles

The SCM is done with <your tool: GIT/SVN other>, a SCM tool that has a command line interface
and integrates with <your bug tracking tool Redmine/trac/mantis/other> task management tool
and the <your IDE Eclipse/other> Integrated Development Environment.

Describe how you manage different versions with branches, forks or other mean offerd by your
SCM tool.
Example:
A main development branch, called the Master, receives by default all software developments
made by the software team. When a new major version is planned (for instance V1.0 or V2.0), a
branch is created from the master. This branch is isolated to be tested, fixed, and finally
delivered.
Use figures! A small diagram is better than a long explanation

Figure 1 Master and branches in the SCM tool

Describe also how modifications in a branch (eg bugs fixes) can be diff-merged in another
branch.

2.2 Configuration management in a development cycle

The changes made by developers during a development cycle are managed by the following
method.
Describe how you manage the development cycle, checkout-checkin of each developer, if there is
an integration branch. How the branch is merged in the current version at the end of the cycle.

2.3 Configuration management of releases

Explain how a release is managed in configuration. Is there a fork, a branch, a tag an so on.

2.4 Configuration management of prototypes

If you have prototypes (not ce marked, not fda cleared) that are released to selected users for
clinical research or the like, explain how they are managed in configuration.

2.5 Tasks in development and maintenance

The tasks depend on the phase of the software development project or of maintenance. The SCM
Manager does the following operations, in the software life-cycle.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Configuration Management Plan of XXX software

Doc # Version: 2013 Page 5 / 7

Event Operation
Launching the development of a new product Creating the source folder structure in the
master branch
Deciding to create a major version Fork of a branch from the current state of the
master branch
Releasing a major version Tagging the current version in its branch.
Archiving the tagged version
Releasing a minor version or a patch Adding a new tag to the current version in the
branch
Archiving the tagged version
Closing an iteration cycle Adding a new tag to the current version in the
master branch
Other events…

The software developers update the source code in the branch that corresponds to the state of
the software and the type of modification.
List the locations of changes

Type of modification Location of the modification

Creating a new functionality in the next major In the master branch
version (iteration cycles)
Creating a new functionality in the next minor In the branch of the major version.
version
Modifying an existing functionality in the new In the branch of the major version.
minor version
Fixing a bug in a released version In the branch of the major version

Fixing a bug in a version in verification phase In the branch of the major version in
(not yet released) verification phase

2.6 Archiving versions

Each version is archived on XXX (a server/network URL …).
The versions are kept in the form of a tree structure, with:
 Source code, configuration files, database scripts,
 Generated binaries and installers,
 Technical documentation,
 …

2.7 Link with bugs and features

Explain how is made the link between SCM tool and bug tracking tool and tasks.
This is important to explain how the link is made. It ensures the traceability of code changes
with tasks/features/bug fixes. This is the main advantage of the integration of tools inside an
IDE. At every iteration, it shall be possible to know what tasks were done and which parts of the
source code has changed.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Configuration Management Plan of XXX software

Doc # Version: 2013 Page 6 / 7

3 Configuration identification
3.1 Identification rules of configuration items
The identification of configuration item is:
 <configuration item name>_Vm.n.p
where:
• "Vm " is the major version of the configuration item,
• n is the minor version number,
• p is the incremental minor version number, if necessary.

The version number of the configuration item Vm.n.p starts at V1.0.0.

The number "m" of major version is incremented when substantial modifications are made to
the device, for example:
 Updating of the intended use,
 Adding new modules / functionalities,

The number "n" of minor version is incremented when non-substantial modifications are made
to the device, for example:
 Adding new functionalities to existing modules,
 Updating the GUI.

The number "p" of incremental minor version is incremented when minor modifications are
made to the device, for example:
 Modifying existing functionalities,
 Minor update of the GUI.

Explain also how versions are identified during iterations.

3.2 Identification rules of SOUPs

SOUPS are identified by:
 The name of the manufacturer,
 The name of the library or software,
 The version if the library or software.

For open-source SOUP without manufacturer name, the name of the open-source project is used.
If a SOUP doesn’t have its own identification, the identification rules in section 3.1 are applicable.

3.3 Identification rules of installers

Discard this section if there is no installer
Installers have the same version as the product they install. If an installer installs more than one
product, the installer version is the concatenation of each product name and version.

3.4 Identification rules of archives

Explain how archives of §2.6 are identified.

3.5 Identification rules of documents

The identification of documents is described below:
XXX-<document number> Rev.<revision index> [Opt.]

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License
 Software Configuration Management Plan of XXX software

Doc # Version: 2013 Page 7 / 7

where:
• XXX is an acronym to identify the project
• " document number " is a incremental in the project,
• " revision index " designates the approved iteration of the document. The revision index
is 01 for the first revision, 02 for the second and so on.
• [Opt.] indicates an optional longer descriptive name.
The revision index is 01 for the first revision, 02 for the second and so on.
Explain also if there is a special rule to identify documents versions during iterations.

This Template is the property of Cyrille Michaud

License terms : see http://blog.cm-dm.com/post/2011/11/04/License