Information Technology Reference
In-Depth Information
Initiators:
User
(sporadically)
Project
Demands
Acceptance
Tests
Support
Hotline
Putting
into
Operation
Integration
Test
Error
Fixing
System
2nd
Level
Fig. 2.4 Error management
Figure
2.4
shows the general procedure after error detection.
With the exception of errors detected during acceptance tests all other errors
follow a support chain normally starting by activating a hotline to a call centre.
Second level support intervenes only, when the hotline is not capable to render a
useful contribution to resolve the error (in this case one has to take into account that
quite often errors reported by end users are due to operating errors; in the following
only real software errors will be discussed). Feedback from technical departments
shall not be discussed here.
The treatment of errors from acceptance tests will be elaborated further down.
This concerns deliveries of corrections during acceptance tests as well.
All corrections are carried out after error reports and corresponding corrections
are tested on the basis of the same acceptance procedures—quite similar to realised
change requests or other acceptance objects—sometimes in abbreviated fashion.
Figure
2.5
details errors types and their corresponding handling processes.
Something subjectively appearing as an error may have different causes:
Real software errors, having been created while converting technical specifica-
tions into code,
Correctly realised requests, but leading to wrong business results during opera-
tion (algorithms, plausibility checks etc.),
Data errors coming for example from data migration from other cross-linked
systems; these can be of various origins and are not discussed any further here.
According to error type the correction process follows its own procedure:
Error correction as mentioned above,
As a change request to initiate a new functional amendment
Passing on to a sub-project, which is responsible for data clean-up.
