For reasons outlined in Section 2.4 of this report the consultant would prefer not to use a system of codes that must be manipulated by the user. It may still be feasible to use codes that remain invisible to the user, but that is not really relevant in this instance. The fact is that the only software so far written to test development of the required type of data bank has used an external set of codes. If the use of these codes is to be avoided, then new software will be reguired.
Hundreds of man years have been devoted to the development of software to handle the types of problems presented by a system such as a data bank of animal genetic resources. It is the consultant's recommendation that a prewritten package be purchased that meets all the current and future (predefined) requirements of the developers.
It is not the consultant's intention at this stage to nominate a specific package, but merely to indicate the options available and provide reasonable cost estimates. A detailed investigation still remains to be done to fully and exactly define the requirements of the proposed system before a final selection can be made. What is more important at this stage is to be aware of what is available and likely costs.
Software packages designed for the database market vary widely both in price and features offered. Systems designed for simple applications (and some not so simple) may sell for as low as US$ 350 while others designed for proprietary operating systems and large volume use may run up to US$ 25 000 and higher. They may in turn necessitate purchase of computers from as low as US$ 3 000 to as high as US$ 250 000.
The consultant has always held the view, from the first exposure to this project, that this application is essentially simple and uncomplicated in terms of user requirements and hence does not warrant extremely sophisticated software that will cost a fortune and perhaps complicate operations for the user in the process. However, there are a few features of the genetic resources data bank that rule out several of the cheaper packages. These are:
- Many packages have been written for microcomputers which will not handle files greater than 8 MB (8 million characters). Although the initial data bank may meet this constraint, it would be unwise to be tied to such a microcomputer and hence package.
- Records must be capable of being stored with variable length.
- The number of traits in each slave record is huge. Many packages will only handle around 60 to 90 fields per record. Although this can usually be encompassed by judicious design of records, it can make overall design and use of the data bank cumbersome.
- The package should be capable of being run on a computer that can at least double or perhaps treble the initial required disc space, to allow an easy growth path.
- The package should ideally be capable of being run on more than one computer should the initial computer run out of steam or otherwise prove undesirable e.g. switching from a single-user to a multi-user environment.
- It should have a simple backup and recovery method to allow for system crashes.
Several packages are available that meet the above requirements. Likely candidates range in price from around US$ 650 to US$ 4 500. This cost, in most cases, would be repeated for each installation, although it is almost certain that a multi-purchase deal could be arranged. Many systems come with two options: the first is to have a package designed by the supplier and to purchase run time code only, the second is to buy the full kit of development aids. The first option is invariably cheaper. For example, one system quoted at US$ 4 500 for all development aids would come back to around US$ 1 800 for a pre-setup solution. The difficulty then lies in making changes. However, it does alleviate the problem of having to have someone skilled in the use of the development aids. Which solution to opt for depends on how well the initial system can be defined and on what level of computer expertise is available at each potential site. Of course, even if there were multiple sites, it may still be possible to purchase the development aids once and allow one site to do all development and ship the new software to the other sites. This would have to be discussed with the original supplier.
The dearer packages are not necessarily more useful for the genetic resources data bank than cheaper packages. They may contain options which are of no relevance e.g. extended report writing, sophisticated searches, optimizing routines, multi-key indexing to make searches faster etc. It is the consultant's impression that speed is not of the essence in terms of extraction of the data (although data entry needs to be streamlined) and that a single-user machine and package would be sufficient. If it is envisaged that several people may need to access the system simultaneously quite soon after initial implementation, then a multi-user system would have to be purchased.
A very accurate costing of the package is not possible at this stage. A further briefing with developers and users of the system is required to discuss finer details to ensure that any package that is purchased can accommodate all needs. Details of validations, internal values of traits, extraction methods, report formats, screen designs, likely occurrence of traits to optimize screen formats and textual descriptions in several languages are just a few examples of matters to be clarified to guarantee that all users of the system have the same perspective of what it can do for them. It is desirable that users meet prior to calling in an outside consultant or software supplier to agree on as many of these areas as possible. This will not only minmize development time but considerably reduce the cost. There is nothing to be gained from a software supplier listening to people argue over what they want out of a system, except to offer advice on some of the options available.
However, for the purposes of deciding whether it is feasible or not to go ahead with the development of the genetic resources data bank, it would be safe to put an upper limit of US$ 5 000 for purchase of software only. This should not be taken to include costs incurred in further liaison and actual development to user specifications. It must be stressed here that you are not buying a final solution. You are buying a package that has the intelligence to create the final solution. It must be informed about many parameters of the system. This can take time.
Once the decision has been made to develop the data bank, the following steps should be taken:
- determine the content of the data bank as fully as possible; this has been partially done already.
- determine the length and format of all traits; this includes deciding which fields will be repeating.
- determine what validation checks can be done as data are entered into the data bank or are modified.
- determine in what order data should be entered; the data most likely to occur in any source document should be prompted first.
- divide data into logical groups; menus can be used to direct the user to entry or modification of these data. If all data within a logical group are missing, then no prompts are necessary.
- determine screen layouts for entry of data to make the process as simple as possible. The operator should not have to resort to memory or large manuals to determine what to do next. This may be influenced to some extent by how the data are currently recorded on paper. Screens should match data preparation sheets.
- determine what data are to be extracted and how these may include some statistical analysis.
- are the data made available from requests to be displayed on the screen, on a lineprinter or both?
- determine the format of any reports required.
- provide reasonable estimates of the number of records likely to be processed.
- obtain agreement amongst users.
Once the system has been well defined and understood by all involved, the system can be either put up for tender or a systematic search can be made of available software packages. Either approach will involve a very close evaluation of several systems. The potential system must:
- meet all needs as determined above
- be readily maintainable either by the supplier or a local expert to cover those inevitable forgotten items or inconveniences
- be economical in disc space
- be simple to use
- be within budget constraints
- be capable of meeting future growth requirements
- be preferably transportable to several computers.
