|
Change control is not optional. All projects are subject to change.
This change needs to be managed. For a simple project with one set of developers
and one set of users you can probably cope with a cheap and cheerful
solution. When you have multiple sets of users or multiple versions of the
system life is much more complicated. For effective change control you are
looking to address the following questions:
- Which files should be in shipped together?.
- Which version of a file was in a particular build?
- Which customers should receive which files?
- Which release was the first to have a particular bug in it?
- Which release was the first where a bug disappeared?
- What is in a particular release? - A release note.
If you cannot answer these questions then you do not have control of your
project. There are several clues that indicate when the project is out of
control due to poor change management:
- New releases are more buggy than old ones.
- The system never seems to stabilize.
- Testers have to continually retest areas.
- No-one knows what is in a particular release.
- No-one knows when a bug has been fixed.
The following areas are suggested as mandatory for all non-trivial IT
projects.
It is amazingly useful if all of these systems are tied together in some way.
I would also suggest to you that paper is not viable.
|