The most basic function of the testbed facility is to test how well we have captured the user requirements and to determine the degree to which our proposed and implemented solution satisfies these requirements. The first function will be addressed largely by a rapid prototype of the Alexandria testbed system constructed during the first phase of the project, while the second will be addressed by the testbed system that will be developed and tested over the life of the project. The rapid prototype system will incorporate all four of the major components of the basic architecture, but will be restricted to one site (UCSB). The testbed system, however, will be a fully distributed system.
The prototype and the testbed implementations of the Alexandria project will involve using widely accepted software engineering techniques for designing, developing, and managing large software projects. The prototype that will be developed by our industrial partner ESRI. Because of the highly interactive and graphics-oriented nature of the Alexandria interface, prototyping is the most effective means of defining and communicating the true set of user requirements as the first step in the application system design and development process.
We propose to use a highly dynamic, interactive, and incremental, implementation-oriented approach to project development. This method will focus on the development of priority application and system components which can be of immediate benefit to the UCSB map and imagery library, while remaining extensible and scalable for future expansion and refinement.
In addition to defining the Alexandria component interfaces, it is necessary to develop a testing approach and test suites for each of the components during the initial prototype phase. These test suites can be used as acceptance tests whenever a new component is to replace an existing one or is to be added to the system. It is also important to develop an integration test plan that specifies the order in which components will be combined and tested as partial systems before proceeding to complete system testing. Finally system test plans should be developed for validating that the testbed meets its overall objectives, such as testing performance requirements, stress testing of large data sets, and testing with unusual data types. The test suites that are developed for system and acceptance testing can be used for regression testing whenever the system is modified. By rerunning these test suites whenever a component is modified or replaced one can quickly ascertain that the system still works.
To achieve widespread acceptance, the prototype and the testbed must also be compatible with standards. Format standards for digital spatial data include FIPS 173 (the Federal Spatial Data Transfer Standard), VPF, DIGEST, HDF, and a host of formal and informal industry standards for raster and vector data. It is also important that the systems be compatible with developing standards for spatial metadata. Our approach to achieving compatibility will build on the high level of knowledge that already exists among the participants in Alexandria, and on our connections with national and international efforts. As part of the metadata research effort, we will sponsor conferences and workshops to promote exchange of information on metadata standards. Finally, it is important that the prototype and the testbed be as compatible as possible with evolving standards in the library community, such as MARC. Our plans for involvement of the library community in Alexandria will ensure an adequate voice for that community's concerns.