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/?RLD25
- 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 productalso 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.