In the regular user application, the major object in the user program is the Test. It's implementation will need to provide efficient access for a wide range of operations, including serial navigation, lookup by date, and filtered searching. Hence, it will need to use a moderately sophisticated data structure that supports these various forms of access. For example, it could use a hashed top-level index, with threading among hash table entries to support serial traversal.
Aside for the Test, the other objects in the regular user Test tool should have reasonably straightforward implementations. The different forms of Test viewing will produce dynamic objects, that need not be exists in persistent storage. Rather, the views are computed form the underlying Test data, displayed on user demand, and then discarded. The Test data structur will need to provide access functions to support the different views.
In administrative application, the major objects are the three databases for Users, Groups, and Locations. The projected size of these databases is probably not big enough to require implementation using a database management system. Rather, some form of efficiently searchable collection should do. The reason this is the case is that there are requirements for sophisticated querying against the databases, and query support is typically the most important reason to employ database management technology.
The distributed processing of the networked Test Tool environment will
require specific development expertise. In particular, the developers need
knowledge of client/server design and implementation. Functionality to support
client/server architectures is available in many modern libraries. It will
make sense for the developers to choose an implementation language in which
client/server support is available, dependable, and well documented.