Dag-Brucken ASRS case study, The

Journal of Information Systems Education, Fall 2003 by Jewels, Tony

The other SA/P had recently completed an undergraduate software engineering degree and had experience in hardware communication systems with a telecommunications provider. His primary role was to design and write a communication system between the PLC and the PC and to design and write the TC module.

The PLC software design was to be carried out by the MD himself, two recently graduated electrical engineers and a more senior PLC electrical engineering programmer. These then, were the people that were initially involved in the early stages of the actual development (as distinct from the pre-planning) stage.

3. THE CONTRACT

The contracts established between DB and its four ASRS clients prior to the commencement of development all contained provisions for staged payments throughout the project life cycle. Payments were to be made at confirmation of completion of milestones, with the actual payment amounts roughly equivalent to DB's proportional outlay for that stage. One of the stage payments for SCT was to be made at completion of the design and development of the control software that was to be used with the system.

Other than the occasional reference to a 'PC controlled GUI' and some arbitrary PC performance specifications there was no contractual obligation to design and develop the software in any particular way. The open nature of the PC software contract specifications reflected the fact that neither contract party clearly understood what a critical role the software component would ultimately play. Clients had entered into these contracts without involving their own IT/IS departments in any negotiation and it was not until after all contracts were signed that the SA/Ps first met with clients to produce the initial software specification. These meetings were also the first instances of client IT/IS personnel having direct contact with DB, although they had already been briefed by their own management.

The contracts contained required performance levels for the completed systems in terms of crane movements per hour and how these performance levels were to be measured, but the formula used was one used for measuring the cycle times of a straight aisle crane. A isle changing performance, constituting the principal difference of the DB system was not included in the contract requirements. Though the system involved the use of two cranes designed to carry two pallets at once, contract specifications only included performance figures for the time to deliver a single pallet on a single crane to locations in the same aisle (Figure 3).

DB were offering a system that had yet to be completely designed, other than in broad conceptual terms, yet clients had entered into contracts that had guaranteed almost 80% of the total price before DB were required to deliver any working system. Stage payments were all at verifiable stages of the design/production process yet actual performance requirements were restricted to performances of the crane that could only be measured in the final stages of the project. Performance requirements for the 'working system' were based on single crane, single pallet, single aisle measurement formulae and did not take into account SCTs production line demands detailed in table 1. At an operational level there was evidence of 'implied' performance levels, with SCT erecting a prominent sign suggesting performance figures of 384 pallets/hour. The contract certainly did not offer this fictitious figure, yet this figure could have been calculated by extrapolating dual crane/fork figures from a single fork performance in a test environment. Yet, as poorly worded and constructed as it was, the contract still remained the principal source of reference for system design and performance matters.