of the applications system rather than on the development of tools on which to base the system. The overall result of this type of decision is usually a substantial.
EXPERIENCE WITH A COMMERCIAL MICROCOMPUTER DATABASE MANAGEMENT SYSTEM H.D. Covvey, N.H. Craven, F. Colman
Clinicom International, Inc., Winnipeg, Canada Cordis Corporation, Miami, Florida
reliability of the company providing the software, and addressing other issues such as cost and ease of use. Recently, several books have reviewed and compared commercial database tools for microcompuSuch books can help in the ters [1]. development of criteria for choosing among the large number of products.
Abstract The designer of an applications system to support a medical database must review a large number of potential packages on The which to base his or her work. number of packages, and their widely differing functional capabilities, costs and performance characteristics make the Having selection process difficult. selected any product, limitations must be faced and some of these will only be found after selection. While recognizing that using such packages is superior to developing one de novo, not realizing the problems and limitations can lead to disappointment, delays and even project failure.
In this paper we will assume that the applications system developer has defined the functional, performance and cost requirements the package must meet, has selected packages that meet most of the requirements and has created a short list. Issues such as cost of software maintenance and ease of use, are assumed to be identified.
This paper focuses on the problems experienced in the final selection of a package, its installation and its use in developing a system. After we reflected on our selection and the problems we faced in implementation, we recognized that every package will have its problems. We believe there are generic and unavoidable problems that will cross They all will product boundaries. disappoint the developer, slow down the development process and increase the cost of development. In this imperfect world, no software package is perfect, and the recognition of these limitations should result in more realistic scheduling and We therefore decided to cost estimates. report the problems and to not identify the specific package we have used.
Introduction Most applications systems designers experienced with the cost of developing information management systems de-novo, the expense of maintaining them, and frequently inflexible and nonexpandable results, today look toward the large number of commercial database management system packages as a basis for their work. By selecting a commercial package, development time can be dramatically reduced, the vendor of the database package can (hopefully) be relied upon to provide software support for the package, and the focus can be on the development of the applications system rather than on the development of tools on which to base the system. The overall result of this type of decision is usually a substantial savings of money and time in bringing a product to market.
Problems in Evaluating, Selecting
and Obtaining Packages
One problem facing the
Reviewing the database packages available, the developer will immediately face the problems of selecting the most appropriate package (there are between 50 and 100 major packages), evaluating the
67
CH2090-9/84/0000/0067$01.00
1984 IEEE
applications
system developer is that many, if not all, database packages are operating system and hardware dependent. Certain packages run only under CP/M, others only under MS-DOS and still others only under UNIX or other operating systems. It is also unfortunately true that a given
personnel with proper training find a number of them superior to programming from scratch.
database package may not run under very similar models of the same hardware product line. For example the package may be available on a single user system, but not available under the multi-user variant of that same operating system or If a the next level of hardware. software package is intended to be transportable across multiple machines in a given product line, or even across multiple hardware manufacturers' systems, then the issue of hardware and operating system dependence must be considered.
final word on the issue of user friendliness, is that menus are good for
A
novices, but they tend to get in the way of sophisticated users. If a system does support menu interactions, it should be possible to bypass the menus when sophisticated users want to use the system. Even if one does acquire a demo package, the limited number of records that can be input prevent a realistic assessment of system performance (the speed of doing a selection from a file based on several criteria, for example). This should be kept in mind and before final selection
We found that we had to look quite closely at the functions supported by the database packages compared to the claims in the advertising literature. Before doing final package selection it is absolutely essential to obtain the complete technical documentation and even a demo version. Demo versions are often available at a very low price. These are modified so that they will only support a At times small number of records. vendors significantly overstated their products'capabilities compared to what we found in testing them.
is done, the application developer should get the actual package and test it with
relatively large files. Finally, it may be that a database package you feel is best will be available "shortly". Unfortunately, estimates of one vendor's product being available in two months, eventually stretched to over six months and meant abandoning it as an option.
Generally speaking any given product is far more rudimentary than some of the descriptive terminology leads the One should look customer to believe. very carefully at claims that the package
Problems in Installing Packages Although we carefully specified the type of system we were using and the media for sending the software to us, we still received demo software on 8 inch floppies instead of on the required 5 1/4 inch f loppies. The result was that we could not install the software immediately and had to go through the laborious process of moving the data from one disk type to another.
supports "a complete data entry system", or a complete "retrieval and query
capability".
Some packages have serious support In one case, despite many problems. calls to the vendor, no software support could be obtained and it was quite impossible to even test run the product.
All packages claim to be "user friendly". Unfortunately, the meaning of the term "user friendly" is very vague. A package
Because of "minor" differences between
operating systems on a given product line, we found ourselves in the position of not being able to install certain packages. A "minor" feature missing from a microcomputer version of an operating system meant a long delay while the
may contain a very easy to use columnar This report generator report generator. may, however, be so restrictive as to be virtually useless for any practical application. On the other hand its more "comprehensive report generator" might require a sophisticated programmer to use it and not be remarkably better than programming in a language such as PASCAL or COBOL. Each vendor claims that its way of interacting with the user is the We would suggest that the best. applications system developer sit down and define the way in which users are going to interact with the database tools themselves (if users are to do so at all) and what level of sophistication of user is expected. Our experience is that most users could not use the more sophisticated query languages or report generators,but applications development
package vendor made modifications to the software.
Sometimes what are apparently minor hardware problems can get in the way as well. For example some of the packages (and one could question the need for this in a database system) require the existence of a floating point chip on the The absence of this processor board. chip means the package will not function. Problems Encountered Once
Applications Development Begins Once the package is installed and running it may become clear that important
68
Some features are weak or absent. packages have excellent data entry systems, others have only the most rudimentary and practically useless data Sometimes a report input capability. generator will actually be useful, in many cases it will only be useful with the help of a programmer, and in other cases the report formatter will be Some systems essentially useless. contain excellent query packages, but this is rare. Most systems have only the most primitive record retrieval capability,sometimes only against a single file or a very limited number of files. Whenever required features are missing from the package finally selected, it will be necessary to develop appropriate extensions to add these features to the package.
Documentation needs to be evaluated at both a user level and at a detailed programmer documentation level. Unfortunately at the deeper levels some of the information is documented only in the brains of the vendor's programmers. We would recommend that all documentation even if there is a be obtained, substantial cost, and reviewed prior to system selection. It is pretty safe to say that most of the packages are skeletons and that a great deal is still anticipated from vendors. It is still better to start with the database packages compared to developing from scratch, but the applications systems developers expectations should not be too high.
Summary of Key Problems
Since many of the database packages are actually quite new products, it may be that the next release will contain the functionality that you require and you may be able to wait for it. We found it necessary to actually meet with our vendor's senior executive to get firm dates for improvements to the system.
Existing commercial database packages for microcomputers are quite expensive. Packages run anywhere from a few hundred dollars to as much as $7,000 for a single copy. Generally speaking it is probably better to look at packages of medium cost as these are functionally superior to most of what we would call "hobbyist"
In the case where you or a contractor must develop key software extensions, it is most important for you to evaluate whether the database vendor has made it easy to interface external routines to Has the vendor provided the package. well-documented means of interfacing external routines? Does the vendor support access to the database package via some standard language (such as FORTRAN, COBOL, C, PASCAL or BASIC)? Will the vendor do development on a Will the vendor contractual basis? provide sources to developers to permit extensions? Will the developer support the product when the extensions are made?
packages.
Packages will be found to disappointingly slow in at least
be some
areas and to lack key features, one of the most important being good query
capability. Packages will be found to have strange and very frustrating physical limits (a limited number of fields in each record, a limited number of files in each database, a limitation that allows only a small number of files to be opened during query and report generation activities, a limited number of bytes per record, failure to support important data types, and many other limitations).
When you actually start to use some of the products you may unpleasantly discover that certain key capabilities For have major performance problems. example in the system we adopted, loading forms composed of multiple screens was an We were only extremely slow process. able to continue using the product because this problem was fixed in an update. We also found that the report generator was extremely slow in producing reports.
Sometimes database packages will take up a very large amount of space on the system disk, a resource that may already be tight in a cost-conscious product. Some of the security systems on the various products are inadequate while others look reasonable.
Perhaps the most important problem we faced was obtaining good support from a Given that all responsive vendor. packages have some limitations and that no package is perfect, the ability to get a question answered can be the key capability in a successful project. Sometimes it is simply a matter of finding a way around the problem. Other times it is getting access to some Th e "undocumented features".
Documentation of packages leaves just about everything to be desired. Certain points in the documentation will be clearly and succinctly written. Other sections may be so badly written as to be In one system we evaluated the useless. poor grammar and general form of the documentation contributed in a major way package. the eliminating to
69
availability of good documentation and excellent software support are probably the most crucial capabilities a product may have. Other than the most trivial applications systems, current database products must be carefully selected within many limitations. As an alternative, however, to developing an information management system from scratch, some packages provide a good starting point and will result in substantial project savings. The key is to recognize that serious development work may still need to be done on absent but important features. Careful study of the vendor, the software, and your own requirements should result in a satisfactory outcome.
References C. Townsend, CP/M Database El] Management Systems. Beaverton, Oregon:
Dilithium Press, i983.
70
