- CM Crossroads (http://www.cmcrossroads.com/), an online community for Configuration Management
- UCMcentral (http://www.snuffybear.com/ucmcentral.htm), Configuration Management Coffee Break Site
- Steve Easterbrook's CM Resource Guide [1] (http://www.cmiiug.com/)
- Parallel Development Strategies for Software Configuration Management [2] (http://www.methodsandtools.com/archive/archive.php?id=12)
- An article on Open source configuration management tools, including references to many of them, see Comments on OSS/FS Software Configuration Management (SCM) Systems (http://www.dwheeler.com/essays/scm.html)
- The subversion (http://subversion.tigris.org/) home page. The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community.
Configuration Management
In Information
Technology and telecommunication, the term configuration management has the
following meanings:
1. The management of security features and
assurances through control of changes made to hardware, software, firmware,
documentation, test, test fixtures and test documentation of an automated
information system, throughout the development and operational life of a system.
Source Code Management or revision control is part of this.
2. The
control of changes--including the recording thereof--that are made to the
hardware, software, firmware, and documentation throughout the system lifecycle.
3. The control and adaption of the evolution of complex systems. It is
the discipline of keeping evolving software products under control, and thus
contributes to satisfying quality and delay constraints. Software configuration
management (or SCM) can be divided into two areas. The first (and older) area of
SCM concerns the storage of the entities produced during the software project,
sometimes refered to as component repository management. The second area
concerns the activities performed for the production and/or change of these
entities; the term engineering support is often used to refer
this second
area.
Sites for configuration management
Software Configuration Management... for
the Technical Writer by Edward B. Toupin
Many software companies with which I've
worked didn't have any type of
process in place for tracking and managing
their software. Usually two or
three lead developers controlled the software.
Everyone else had to work
behind them to update or integrate their individual
components. As the
projects grew, developers became confused, management
became frustrated, and
writers quit because it was hard to keep up with so
many simultaneous
changes.
--- What is Software Configuration
Management? ---
The purpose of Software Configuration Management (SCM) is
to identify the
state and configuration of a software project and be able to
control changes
to maintain the software's integrity, traceability, and
accountability
throughout the software life cycle. The core objective of SCM
is to bring
control to the development process through:
- increasing
development productivity,
- supporting better control over the project,
-
supporting better project management,
- reducing errors and bugs,
-
supporting faster problem identification and bug fixes,
- improving customer
goodwill.
One problem is that a single SCM solution is not suited for all
projects.
While the core SCM objectives and functions remain the same, the
SCM system
has to be tailored for each project.
--- SCM Process for
the Technical Writer ---
Many software projects I've seen changed course
daily. One day the product
worked one way, the next day it was completely
different. Many of the
writers at these companies walked out the door
mumbling that "the company
wasn't ready for documentation."
Actually,
this is the norm for many newer software companies and you'd be
surprised how
ready they are to have you!
When working on software documentation, it's
important to either get
involved in the SCM process, or put one in place so
that you can always have
the most recent version of the software with which
to work. Of course, you
can't afford to spend days working on a complete
process that, in the mean
time, won't be adopted by the company. However, you
can take a piece of the
puzzle and use it to your advantage.
Of
course, once development settles down a bit, you'll have a real product
to
work with. But, in the mean time, you have the core product that you can
use
in your task analysis and research. This single step will place you
leaps and
bounds in front of other writers who give up because of the
ever-changing
state of a product!
The general steps of an SCM process are described in
the following
subsections. Your knowledge of these processes can enhance the
development
and deliverables for any software project!
* Source Code
Versioning and Tracking
Source code versioning and tracking is usually
handled by some type of
source safeing application. The application is used
to store and track
different versions of the source code so that developers
can maintain an
archive of changes without the fear of losing any level of
previous changes.
Source safeing applications save each new version of
the code by archiving
the differences between previous versions. If you want
to go back to a
previous version of the code, the application rebuilds the
selected version
from the differences.
If you have numerous files in a
given project, you can tag a set of files
with a symbolic name. This symbolic
name can be used to extract all files
for a release or version number so that
you can group all current project
files together.
The most popular
source safeing applications include the following:
- Visual Source Safe:
http://msdn.microsoft.com/ssafe/Prodinfo/?RLD=25
- PVCS: http://www.merant.com/products/pvcs/
- RCS: http://www.componentsoftware.com/
- CVS: http://www.cvshome.org/
You should talk to the system administrator to obtain access so that you
can
download the code. Not only will you be able to better understand
what's
going on in the application by reading the code, but you can access
the
various headers to develop Application Programming Interface
(API)
references as required.
* Installation Builds
It's the
responsibility of the developers to determine and acquire all
files
associated with a given installation. All files should be uploaded into
the
source safe system and tagged. Once a new tag is created, you can
download
the version onto a build machine and create a new version of the
product. In
some cases, this responsibility is handed off to a Configuration
Manager,
however, your purpose for getting involved in the SCM process is to
develop
solid documentation...not manage the source safe.
Ideally, as
part of an SCM process, the build process should occur at least
once a week.
It's a good idea to talk with the developers so they can notify
you when they
tag a new release. In this way you are obtaining a complete
and up-to-date
set of files to build the most current product.
* QA
Quality
Analysis and testing are important parts of the SCM process as this
is where
problems are found and the product can be evaluated to see if it
meets the
standards and requirements for the project. For your purposes, you
can
provide a set of basic tests by creating a Task Analysis and a simple
Test
Plan.
The Task Analysis provides a set of steps that must be executed to
perform a
specific operation with the product---also part of Documentation
Analysis.
It's essential that the Task Analysis be performed for each major
update to
the software to ensure that the changes are carried through to
the
documentation.
* Bug Tracking and Resolution
Bug tracking and
resolution are not only part of the SCM process, but are
also used with
Change Management. It's essential that bugs be reported and
that developers
are notified of the problems to ensure resolution. But,
resolving a bug can
place the product into deeper jeopardy when, in some
cases, the resolution
introduces another set of bugs.
This is where a Feature Update document
comes into play. Whenever a change
is made to the software, to either resolve
a bug or change the
functionality, the Feature Update document assists in the
tracking of the
changes. Additionally, Feature Update documents can be used
as addendum to
the documentation until the actual content can be
updated.
Some of the more popular bug tracking and management systems are
as follows:
- TestTrack: http://www.seapine.com/
- Gnats: http://sources.redhat.com/gnats/
- Bug Wiser: http://www.hallogram.com/bugwiser/
As you evaluate the newly built product, keep track of various problems
you
encounter and report them back to development. In this way, you can
provide
a service for the development staff as well as learn the various
issues
associated with the product itself.
* Packaging
Products
available for release should be presented as a completed and
tested
installation on CD and over the Web. For CD installations,
documentation can
be provided in HTML or PDF format. All installations should
auto-start when
inserted into the CD drive or be started by double-clicking
on the setup
application.
For Web-based installations, the basic
installation information is located
on the Web page associated with the given
download. Once the product is
installed, the user can read detailed
documentation from an HTML or PDF
file.
Some of the more popular
packaging systems include:
- InstallShield: http://www.installshield.com/
-
Wise Solutions: http://www.wisesolutions.com/default.htm
* Deployment
Web-based deployment can consist of a Web page with
a link to the
installation executable. The user can access the page, read the
instructions
for installation, then click on the link to download.
CD
based deployment can consist of a full installation copied to a CD. The
user
can access the CD, read the instructions for installation from the
online
documentation, then maneuver through the installation.
* Customer and
Technical Support
All products should come with a User-Acceptance Test
(UAT). For custom
products, the UAT ensures that the product meets a minimal
set of
requirements originally defined in the Requirements Analysis document.
The
UAT allows the user to feel comfortable that the product meets their
needs
and functions according to their requirements. For off-the-shelf
products,
the UAT ensures that the product is setup properly and functions in
the
user's environment.
Customer and technical support are essential
in that, once the product is
out in the field and in use, the customer needs
some way of reporting bugs
that were missed during QA. It does happen, but a
solid QA process should
capture a good percentage of the problems before
deployment.
Additionally, the customer will need to access a portion of
the bug tracking
system to monitor progress on their trouble tickets. This
makes the customer
feel better about the product and the process if they can
monitor the status
of their issues and reports.
--- What's next?
---
Numerous new software companies don't have the time or the desire to
put a
proper SCM process in place. Such a process not only helps in
the
development, but it also assists in the documentation. In such a
situation,
it's important that you understand the basics of SCM and various
software
development life cycles. Not only will you be able to generate a
solid set
of documents, but you will also assist the development of a
solid
infrastructure for the company's development team!
About the Author
Edward B. Toupin is a freelance consultant,
writer, and published author
living in Las Vegas with his singer/actress
wife. He currently handles
technical writing tasks for various companies in
New York, Chicago, and
Denver as well as imagineers and markets
feature-length screenplays.