Software design w liv 0269 upgrade latsa software.

Upgrade of LATSA Page 12 of 148

3.3 Software design

and specification A review of version 1 of LATSA established that the main areas requiring improvement were those previously identified in the terms of reference for this project refer Section 2, above. This was reinforced by a consultative meeting held with MLALiveCorp staff and industry representatives in Brisbane on 16 February 2010. In the review it was found that version 1 of LATSA consisted of hard written data tables for specific livestock types or classes together with output values. Across all species, the available livestock types were limited to less than ten selections. The number of selections was consistent with SAE AIR1600. The physiological data appear to be drawn from graph presented in literature reviewed during the originating project, and so were restricted to the few animal types represented in that material. While version 1 of LATSA ensured that a process was in place to guide exporters participants through the system and provide a definitive answer, it does not have the ability to match all consigned loads. In addition the software does not provide any computational analysis of either animal physiological parameters or aircraft ventilation. Version 1 of LATSA contained aircraft model and general capacity data but the linkages between operators and aircraft were incomplete in the basic version. The expectation was that these were to be manually updated by users or loaded via a software update. The use of lower holds, deemed important by AQIS was dealt with via a simple yesno checkbox and the assignment of livestock to various aircraft holds was not available. Through the review of version 1 of LATSA, and a review of the objectives, it was determined that software needed to be reconstructed, rather than simply modified. A small portion of the original Microsoft® Access database, principally the aircraft, operator and airport tables, was capable of being extracted and expanded to include all the data required to fulfil the project objectives. Version 2 of LATSA was required to be internet based. The decision was made to construct the database in an SQL environment, which required placement on an SQL server. The user interface has been written in Microsoft® Visual Studio 2, and presents itself in a similar fashion to many HTML based internet sites. The computation analysis forming the backbone of the system is written in ASP.NET VB Net. The intellectual property associated with the source code remains the property of Meat and Livestock Australia Limited. The database tables have extensive inter-relationships. Many of the tables and fields are more extensive than the basic requirements of the project objectives. A decision was taken to provide some ‘future proofing’, by providing the ability to collect and store additional information, which could be utilised in future upgrades of the software. Coupled with the methodology and documentation of the source code, this will ensure that minor upgrades of the software are cost effective. The source code encapsulates all the calculations referred to in this report. Computational results are not hard written to database table field. This allows real time correction of results when changes are made to source data i.e. that entered by the user through the consignment window. There are two access points to the data tables. Firstly, administrator access allows the system operator to add new data for aircraft, operators, crates, users and other information, which is not accessible to the general user. Through normal business process controls, this restricts the Upgrade of LATSA Page 13 of 148 manipulation of important information such as hold ventilation data and crate details, much of which has a very significant impact on the results obtained in the general user area of the software. Secondly, the general user participant or exporter has access to the Consignment pages of the software. This allows the exporter to load all consignment information; assign crates, animals and aircraft holds through load lines; obtain results based on each hold utilised; and extract overall data such as flight time and total weight. In addition, the exporter can retrieve general consignment information and the required data for exportation documentation. The field linkages within the table structure allow for selection of variables, such as operators, aircraft, holds, manufacturers, crates and animals in a related manner. Where data is not linked by the System Administrator, it cannot be selected. As an example, where a crate fits only one aircraft hold e.g. Boeing 747-400 main hold it cannot be selected in any other aircraft or hold – it will simply not be available for selection e.g. A340-300 main hold or Boeing 747-400 lower forward hold. In addition to field linkages, there are compliance fields within the operator, aircraft and hold tables, which restrict the use of the appropriate data if it is deemed non-compliant by industry or the regulating body. This compliance check may be as specific as one hold of one plane for one operator. Again, where data is non-compliant, it will simply not appear in the selection list. The default for all data selection is off, meaning that no selections will appear unless they have been setup by the System Administrator. Upgrade of LATSA Page 14 of 148

3.4 Compilation of aircraft and crate data