8.3 Event Registration

There are various types of events:

  • A review observation for a document

  • A waiver (a statement that a customer waives a given requirement)

  • An error report from a test run

  • An inquiry to a helpdesk concerning a finished product already in operation

Some events may be planned (the first on a list), while others cannot (the last on a list). Event registrations are input to change control.

Life Cycle and Responsibility

An event must go through a defined life cycle. Typical event phases may be

  • Created

  • For evaluation by the producer of the affected configuration item

  • Under decision by the configuration control board

  • Under change in accordance with change request(s) attached to the event

  • Closed

The general responsibility for driving an event through its life cycle lies with the configuration control board. It may hand over the responsibility, for example, to the person responsible for development, the author, or the tester. This general responsibility is not included in the event registration, as it's a management decision on a higher level.

No matter which phases are defined for an event, phase information must be registered successively as the event runs through each phase. It may be practical to save the registration history for an event registrationinformation on the phases the event has gone through and the time of those phasesand not just overwrite the earlier phase, date, and time when a new phase is started.

It may also be practical to keep the possibility open for an iterative course, so that phases may be run through several times. For instance, the configuration control board may send an event back to evaluation by the producer. The phases mentioned above must be regarded as the minimum course.

Content

There are numerous ways to frame an event registration. No matter which way is chosen , it should contain the following data elements:

  • Configuration item concerned

  • Information about the event: identification, event type, and short title

  • Phase information for the event: phase, date and time, name of person responsible, name (s) of other people involved, description, and classification

Configuration Item

The configuration item in which the event is found must be indicated as precisely as possiblepreferably with the unique identification. If the item is a delivery, the delivery should be identified, if the person who has observed the event cannot immediately identify the precise single item to which the event is attached.

Identification

Each event registration must have a unique identification. This will typically be a number in a specified seriesone series per product, project, or event type (or some combination).

Event Type

A company may choose to carry out event registrations in different ways and with different content, according to the type of event, such as paper-based review observations and error reports from tests in one database and communications with helpdesk in another. It is also possible to make type information part of the content. Event types may be review or inspection, test (which may be separated into module test, integration test, and accept test), internal use, and customers' use (production).

Title

An event registration must be given a short, informative title. This will give an easy general overview, such as in lists, over outstanding or corrected errors.

Phase Indication

A phase indication or equivalent status code will show where in the life cycle a given event registration is or was at a given time. The phases or status codes that have been defined and that must be used should be expressed as unambiguously as possible. This may be as a section heading on a form or as an entry on a selection list in a database.

Date and Time

The meaning of this data element is the same for all phases: the point at which a phase is started or a certain status has been attained. This must be expressed as precisely as possiblein any case, at least as a date. It may be appropriate, for the sake of metrics concerning elapsed time, to express the status time with greater accuracy.

Created

In this phase, the rest of the data elements may have the meanings shown in Table 8-1.

Table 8-1. Data Elements for Event Registration in the Creation Phase

Data Element

Meaning

Name of the responsible person

The name of the person who has created the event registration. It may be the observer, but it may also be a person at a helpdesk.

Name of observer

The name of the person who has observed the error, such as a customer or a test consultant.

Description

The description must contain a comprehensive description of the event itself and its circumstances, so the event can be reproduced or immediately understood . Reference to other information should be possible, such as screen dumps or the precise time of the event. The description may also contain a data element for a suggested solution.

Classification

Classification will be provisional, based on the data supplier's view of the situation.

For Evaluation

In this phase, the rest of the data elements may have the meanings shown in Table 8-2. As for the estimated time required to solve any problems, a checklist for assessing the effects of any changes may be found in Chapter 1.

Table 8-2. Data Elements for Event Registration in the Evaluation Phase

Data Element

Meaning

Name of the responsible person

The name of the person who must take care that evaluation is carried out. This will typically be the project manager, group manager, or the like.

Name of information supplier

This will typically be the producer or some other person with equivalent expert knowledge of the affected configuration item.

Description

This may be divided into these data elements:

  • Suggested solution

  • Workaround for the problem, if any

  • Affected configuration items

  • Other affected objects

  • Estimated time for effecting the solution

Classification

Classification will be provisional, based on the information supplier's view of the situation.

Under Decision

In this phase, the rest of the data elements may have the meanings shown in Table 8-3.

Table 8-3. Data Elements for Event Registration in the Decision Phase

Data Element

Meaning

Name of the responsible person

The name of the person who must take care that a decision is reached. This will typically be the person who is responsible for configuration management or the project manager.

Name of information supplier

This must be the configuration control board for the item in question.

Description

A short argument for the decision that has been reached. The decision will be shown in the subsequent phases, which may be

  • To be changed

  • To be closed as a duplication of . . .

  • Rejected

  • Postponed to . . .

Classification

This will be the final classification made on the basis of a closer assessment of the event.

Under Change

In this phase, the event is transferred to the change request(s) the configuration control board has created to make changes. The person responsible for this phase will typically be the project manager or a group manager. The rest of the data elements have no relevance for this phase.

Closed

In this phase, the event is closed. This may happen as a consequence of approval of all attached change requests or of rejection of the event. The configuration control board will be responsible. Further data elements have no relevance for this phase, unless one wishes to give a reason for the closing of the event here. It may, moreover, be appropriate to indicate when information has been given back to the person or people who once observed the event.

Classification

Events may be classified according to these classes: omission, gold plating , fault (which may be divided into several categories or types as required), inappropriateness, enhancement request, not reproducible, and information (not a fault). Many examples of classification and taxonomy of errors are given in the literature.

Examples

This section contains two examples of event registration formsone for a configuration management system with a low degree of formalism and one for a high degree of formalism. In systems of the lowest formality , e-mail may be used to communicate events.

Low Degree of Formalism

Figure 8-7 shows an Excel workbook used to register and follow events. All project members may access the workbook, and event entries may be sorted by any of the columns to produce various overviews of the information. The file e1.doc may contain a further explanation of the event, possibly including screen dumps.

Figure 8-7. Excel Workbook Used for Event RegistrationsLow Degree of Formalism

graphics/08fig07.gif

High Degree of Formalism

Figure 8-8 shows an event registration form. It may be used to follow each event during its life cycle and for signatures for documentation of progress. Since the life cycle of events can be complicated, a procedure describing the life cycle and how to register information is useful.

Figure 8-8. Full Event Life Cycle Registration FormHigh Degree of Formalism

graphics/08fig08a.gif

graphics/08fig08b.gif

Event registration today will seldom be on paper. Many good tools, some even freeware, will handle event registration, and it's also fairly easy to make one's own system with modern office tools, such as Access. In some cases, such as with remote users, it may be necessary to first create event registration on paper and later transfer the information to a system. Figure 8-8 gives an idea of the information to collect for an event and may also serve as inspiration for the layout of a full event report.



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