Information Technology Reference
In-Depth Information
take on the form of a contract. This contract describes the specifics of delivery and
other characteristics of the software as well as modes of payment. This contract thus
presents a document of legal relevance.
The settlement of the delivered product can follow directly with reference to the
contract, once all agreed upon details have been met. Auditors require that the
delivery has to be documented in one form or another. This is done most appropri-
ately at that place and at that time, when the correctness of the delivery is
assessed—in our case at the end of acceptance procedures by a proper protocol.
Details will be discussed further down. However, one has to differentiate
between a rather technical validation by an acceptance protocol with error docu-
mentation and a conclusion on this basis with a view on a recommendation how to
deal with the results. Both points of view may of course be included in one and the
same document. The final evaluation of acceptance tests will thus cover references
to the acceptance objects, to acceptance procedures and a documentation of the
results including error protocols. Furthermore it may contain only one out of two
possible conclusions:
Not accepted or
Accepted.
Concerning the latter, qualifying understandings can be included. They may
contain obligations, only under which the acceptance is valid. In most cases this
concerns measures agreed upon between customer and supplier to amend few but
important software errors not having been resolved up to the end of testing.
3.4 Basics for Acceptance Procedures
Let us first consider some conventions and rules.
3.4.1 Dates for Provisioning
One has to differentiate between three different provisioning dates:
PfT
Provisioning for Tests.
This is the date after the preliminary end of all development work. The
developers hand over their results to the internal quality management of the
supplier. Included are technical test scripts, which are necessary to test the
functional features of the software. The software either resides on the various
individual development systems or on a common configuration expressly con-
ceived for internal acceptance tests (factory approval). Tests are carried out with
synthetic data. The participation of the customer is formally not required, but
may be of use for practical reasons. As soon as functional errors become visible
¼
