Information Technology Reference
In-Depth Information
3.3.4 Overall Planning of Acceptance Tests Together
with the Supplier
An important implementation project normally rests on an overall project plan
agreed upon by all sides with all tasks and mile stones. Software acceptance as part
of a complete release does appear only as a single mile stone, other acceptance
objects do not appear at all—only if they represent strategic business functions.
This means that, when acceptance time comes near, detailed scheduling on a day by
day basis has to be drawn up. Since supplier resources have to be included close
consultation taking into account his interests is indispensible.
Acceptance planning does not only deal with start and end dates for example
regarding system provisioning and the testing period itself, but has to consider
every function to be tested with all necessary specialist resources. Certain constel-
lations may require that parallel testing of specific functions accessing one and the
same data base has to be avoided (competing accesses, locking, risk of corrupting
the data base etc.). For these cases separate time windows have to be provided. The
resulting schedule, which initially is binding for the complete testing period,
assigns specific functions and time windows to every resource. During acceptance
testing itself, however, adjournments occasionally have to be considered because of
follow-up tests, after error amendments have been carried out.
The exact format of an acceptance schedule itself is of minor importance. Only
when extensive software is to be tested for the first time a thoroughly time-phased
project plan should be drawn up. But also for such a case parts of it can be presented
in simple EXCEL
sheets. The important things are clarity and ease of update.
©
3.3.5 Management of Acceptance Procedures
This core responsibility requires the agreement of all parties concerned: business
units, project and supplier. Furthermore, backing and early communication has to
come from top management. On top, the responsible quality manager should be a
socially and professionally respected person, possessing assertiveness as well as
diplomatic skill to handle compromises. It is important to provide satisfactory
software solutions in good quality and in time and thus be able to pay the supplier
his due. This is the common objective, which should not be impeded by a drive to
perfection without compromises.
3.3.6 Final Evaluation with Recommendations
Prior to developing software there has to be an order for realisation unless the
software is bought off the market shelf by the customer. Normally orders usually
