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
software. Everyone else had to work behind them to update or integrate their individual components. As 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 state and configuration of a software project and be able to control changes to maintain software's integrity, traceability, and accountability throughout software life cycle. The core objective of SCM is to bring control to development process through:
- increasing development productivity, - supporting better control over 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 core SCM objectives and functions remain same, SCM system has to be tailored for each project.
--- SCM Process for Technical Writer ---
Many software projects I've seen changed course daily. One day product worked one way, next day it was completely different. Many of writers at these companies walked out door mumbling that "the company wasn't ready for documentation."
Actually, this is 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 SCM process, or put one in place so that you can always have most recent version of software with which to work. Of course, you can't afford to spend days working on a complete process that, in mean time, won't be adopted by company. However, you can take a piece of 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 mean time, you have 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 ever-changing state of a product!
The general steps of an SCM process are described in following subsections. Your knowledge of these processes can enhance 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 source code so that developers can maintain an archive of changes without fear of losing any level of previous changes.
Source safeing applications save each new version of code by archiving differences between previous versions. If you want to go back to a previous version of code, application rebuilds selected version from 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 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 system administrator to obtain access so that you can download code. Not only will you be able to better understand what's going on in application by reading code, but you can access various headers to develop Application Programming Interface (API) references as required.
* Installation Builds
It's responsibility of developers to determine and acquire all files associated with a given installation. All files should be uploaded into source safe system and tagged. Once a new tag is created, you can download version onto a build machine and create a new version of product. In some cases, this responsibility is handed off to a Configuration Manager, however, your purpose for getting involved in SCM process is to develop solid documentation...not manage source safe.
Ideally, as part of an SCM process, build process should occur at least once a week. It's a good idea to talk with 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 most current product.
