Software Configuration Management (SCM)
• Software Configuration Management (SCM) is
a) the development and
b) the application
of standards and procedures for CONTROLLING
all software artifacts produced in the development
and support of software.
• Major Activities for successful SCM:
1.
2.
3.
4.
5.
Overall planning of development and application of SCM
Assigning responsibilities to develop SCM system
Rollout the standards and procedures for implementation
Implement and practice (enforce) the procedures for SCM
Track the progress and make necessary adjustments
Over-All Planning for SCM
• Major areas of planning
1. What is the development and support process
utilized and thus what are the artifacts that need to
be identified, inventoried and managed ?
2. Who is responsible for the various aspects of SCM ?
3. What are the key procedures and policies ?
4. What tools are needed and how much other
resources are needed ?
5. What is the impact of SCM and relationship to other
activities ?
Software Artifacts to be Managed
• Depending on the process, the identified milestones
and the committed deliverables, the list of items
that need to managed may be different; but many
of the following are included.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Requirements and Change Requests documents
Project, Quality, Test and various plan documents
Architecture/Design documents
Prototype code and documents
Implementation Source and Object code
Test Scenario documents
Test cases, test input data, and testing results
Installation guide document
User Guide, etc.
• The identification of what artifacts will be
inventoried and managed must be completed.
Types of Artifacts to be Managed
•
•
•
•
•
•
Documents : Text, Diagrams, Spread sheets, etc.
Code : source code text, executable object code
Data : data in some file or database
Pictures : Bitmapped photographic images
Audio : sound bytes of speech, music, etc.
Video : audio and images
Code is the most common, and sometimes the only, artifact that is managed
Example of: Inter-relationship and Intra-relationship of Artifact Types to be Managed
Test Scenario
Version 3
Specification
Version 2
Code
Version 3
Test Scenario
Version 2
Should this
be version
1.1 instead ?
Code
Version 2
Specification
Version 1
Code
Version 1
Test Scenario
Version 1
Responsible parties for SCM
• Planning and Impact Analysis of SCM
– management personnel
– process, quality assurance and configuration administration personnel
– software implementation personnel
– tools personnel
• Designing the procedures and policies
– process, quality assurance and configuration administration personnel
– tools personnel
• Implementing and running the tools
– tools personnel and configuration administration
• Participants in implementing & using SCM
–
–
–
–
the complete development organization
subcontract personnel
consultants
customers
Key Procedures and Policies
• Naming Convention for the artifacts must be able to allow
the unique identification of each artifact that is inventoried
and managed. An example of 6 part product release
naming convention:
– pp.cc.vvv.rrr.ttt.fff where
• pp is the product code (if numeric then this gives 100 unique
products such as financial application, Java compiler, etc.)
• cc is the country code (if numeric then this gives 100 countries such
as US, French, Japanese, UK, German, Chinese, Spanish, etc.)
• vvv is the version code (if numeric then this gives 1000 versions
such as the MS Win98 version, UNIX version, LINUX version, etc.)
• rrr is the release code (if numeric then this gives 1000 releases such
as release 1, or release 2, etc.)
• ttt is the type code (if numeric this gives 1000 types of material
such as design doc, req. spec, test case, source code, etc.)
• fff is the format (if numeric this gives 1000 types of format such as
text, spreadsheet, jpeg, binary, etc.)
Key Procedures and Policies (cont.)
• Naming Convention and Promotion Scheme for
product under development or in support is a
little different.
– There must be a clear rule about promoting the artifact from
one stage of development or support to another.
– Once the artifact is promoted to a certain stage, it is locked at
that stage.
– It is also important to promote related artifacts such as code,
help text and test cases
.
.
promote
Private Copies
promote
Formally
Inspected
promote
Functionally
Tested
promote
Integration
& System Tested
Golden
Copy
Key Procedures and Policies (cont.)
• Micro view of policies on control of an artifact that
need to be created, accessed, and deleted.
– Create : an artifact may be created for the first time
and assigned a unique identifier
– Delete : an artifact may be destroyed and its unique
identifier is returned to the pool.
– Access: an artifact may be accessed:
• view only : no conflict in viewing
• modification purpose : there may be conflict in that multiple
parties may be accessing the same material for modifications, but
the result of modifications when returned will be out of synch.
There needs to be check-out and check-in rules for artifacts
• Lock/unlock : disable and enable accessing
Key Procedures and Policies (cont.)
• System build : is a process where all the necessary code and
code libraries are brought together and compiled and linked
so that, as a set, the code will run. This process is extremely
important during testing of large system with multiple
participants and/or geographically distributed participants .
• Build cycle may be daily or weekly or semi-monthly
– All the changes to the artifacts must be submitted prior to
the build cycle via a pre-set time frame or by build
administrator’s announcement.
– A build tool is almost a must where artifacts that are not
changed are picked up from one library and those that are
modified are picked up from another so lengthy recompilation time may be saved.
More on Build (Partial Build)
• A build in its simplest form is just compiling
and linking a single program.
• A build with lots of programs and lots of
library functions will need a “script” or a set of
“instructions” to tell the system
–
–
–
–
–
Which source code
Where are all the source code
Where are all the libraries
In what order to compile the code
The order the code needs to be linked
1. For testers and code fixers, they only want to test a few modules and fix the
modules associated with the testing discovered problems.
2. So, they rarely want to build a complete system for a test or re-test --- only the changed
modules.
3. But ---- they may not know all the relationships --- causing multiple errors in the build
script for these “partial builds”
Main “Mechanisms” for SCM
1. Product “Versioning and Release” control tool
that can handle complex naming convention and a
complex product inventory scheme.
2.
Artifact creation, modification, promotion,
locking, and deletion mechanism which allows
multiple and geographically distributed
participants.
3. System build process that can create a complete or
a part of the system for both:
–
–
constant and regular build cycles
final “golden disc” for release
Some “Popular” SCM tools
•
•
•
•
•
•
•
Rational Clear/Case - IBM
CMVC - IBM
PVCS – Serena
Visual SourceSafe – Microsoft
Team Foundation Server - Microsoft
Concurrent Version Syst. (CVS)– Open-Source
SCCS – UNIX (comes with)
Some Interesting “Technology” Related to SCM
• Storage and access of the artifact:
– complete copy every time
– first copy but only the modified part for subsequent
copies
– mixture of one original copy for each version’s first
release but just the changed parts for subsequent
releases
• Super compare algorithm for searching out the
changed artifacts and the specific changes.
• Information linkages of :
– Who uses information X (e.g. module fan-in sources or
requirement to design to code)
– Whom does information X use
“Topics” Related to SCM
• Change Management where all changes must be:
–
–
–
–
requested
approved
completed
stored
• All change management activities need to be
performed and records kept within the SCM system.
• A key artifact needed to track changes is the change
request form which depending on its usage may be
complex or simple: e.g.
–
–
–
–
request submission source, reason, priority, and date
request estimated impacts on schedule , cost, product, etc.
status : approved, denied, in development and test, completed
actual impact on schedule, cost product, etc.
“Topics” Related to SCM (cont.)
• Quality Assurance Management to measure and
track quality: e.g.
– relating number of changes to number of failures in
error prone analysis
– relating “ where used” information in SCM to fan-in
and fan-out information
• Process & Project Management to track and
measure productivity, cost, and schedule: e.g.
– using linkage information to relate certain
requirements to cost and schedule
SCM Roll-Out and Implementation
• All SCM related standards and procedures are
defined and agreed to by the organization.
• All SCM tools are installed and support personnel
are in place.
• The complete organization and especially the
users are trained on the procedures and the tools.
• All the groups in the organization has committed
to using the SCM system and implementation or
pilot implementation is started with some kind of
broad announcement or ceremony.
Track & Audit SCM Usage
• Personnel, both technical and administrative,
must be ready to support and track the usage
of SCM system.
–
–
–
–
Capacity of resources
Number of transactions
Number of problems found and resolved
etc.
• Funds must be allocated for continual
maintenance and upgrade of the SCM system
itself