15.3 Emergency Changes

In special situations, it can be necessary to break all rules and carry out an emergency correction. This may occur in all development activities in a product's life, but it's probably most common in maintenance.

Examples

A company has issued a document in version 1.01 as an updated version after review. The document is many hundreds of pages. Afterward, the author discovers he or she has forgotten a correction on page 43. The correction has been approved and only has to be entered. Should she just make the correction and bring out a new page 43 in version 1.01, or must the entire document be issued in version 1.02, as prescribed by the procedure?

An engineer is going to install a new version of a software system far from home. A serious error is discovered in the delivery shortly before the engineer is to leave. If the error is corrected in the prescribed way, the engineer will miss his plane and the installation will be postponed at least a week, with considerable damages forthcoming. If the error is not corrected, the engineer's trip will be in vain, and the company will still have to pay damages for late delivery. What can be done?

A large system is running in ordinary production but goes down in the middle of the night. The programmer is sent for and finds an error in a program. Should she get the system to run straightaway, or should she wait for the next working day and have the event treated in accordance with existing guidelines, which say that the chairman of the configuration control board must sign the event registration? The guidelines don't say she's allowed to wake the chairman at three o'clock in the morning!

Principles for "Cheating"

A company may have substantial reasons to bypass configuration management in special situations, and a way to identify and allow handling of exceptions should be built into the processes. What is important is that things appear exactly as they are, with nothing swept under the carpet. It must be clear to everybody involved that processes are being bypassed. When deciding whether this can be allowed in a given situation, the following must be considered :

  • Does it contribute positively to the company to bypass processesor does it give a short-lived gain that will be detrimental in the long run?

  • How can the way processes have been bypassed, and the reason, be made unmistakably clear to everybody?

  • How can existing processes be changed to handle this type of situation?

Allowing processes to be bypassed in special cases may contribute to acceptance of configuration management, by diminishing the idea of the system as existing for its own sake.

Avoid Cheating

Bypassing processes must never become a habit. If it seems necessary to bypass processes too often, and especially the same processes time and again, something is seriously wrong. An unnecessary bottleneck may be built into a process, such as if approval must be obtained from a person who is only rarely accessible or if it takes too long to handle an event registration. One should not close one's eyes to the fact that exceptions occur, because such cases are a good source of inspiration for improving the system.

Examples Again

In the first of the examples of emergency changes, the solution could be to issue page 43 in version 1.02, together with relevant new pages, such as the document identification page (typically the front page) and history page, both with an indication of the new version and its grounds. The change in the process description is that it takes into account the possibility of issuing single pages in a new version.

The solution in the second and third examples could be to obtain oral permission from the proper people to correct the error if this is in any way possible, correct it, and afterward get the necessary registration work done. This could be a posthumous event registration and the ensuing handling of a change requesta registration of decisions and actions after they have actually been performed. The change in the process description is the addition of guidelines for such cases



Configuration Management Principles and Practice
Configuration Management Principles and Practice
ISBN: 0321117662
EAN: 2147483647
Year: 2002
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net