This document is here to provide an overview of the process we will be using to define the standards for the Invasive Species Systems Task Group that is a part of the Invasive Species Interest Group (ISIG) for the Taxonomic Database Working Group (TDWG). This group is connected with the Global Invasive Species Information Network (GISIN).
The purpose of this group is to define an Invasive Species System to share invasive species data internationally between a large number of computers (providers). The system will consist of a web service communication protocol and any required directories, portals or other web sites. The system will include a toolkit for providers if required to make implementation of the protocol easy.
Below is the software lifecycle the group will be following. Excellent background information for software development is provided by the Rational Unified Process series of books (Kruchten 2000).
The software lifecycle breaks the development process into the following steps:
1. Investigation: Determine user needs, technical feasibility, and available alternatives for implementation
2. Design: Create the design for the system to be implemented. This typically includes object-oriented design techniques and prototyping to investigate design issues.
3. Implementation: Writing of the final software. For a standard this typically includes the toolkits provided to users and test tools.
4. Quality Assurance: Testing of the software. For a standard this includes testing the functionality of the toolkits and insuring the protocol meets the requirements defined during the investigation. Typically testing includes in-house or “alpha” and user-based testing prior to release or “beta” testing.
5. Delivery: Shipment of the product to users. For standards development this includes delivery of the toolkits and follow up to insure the toolkit meets the expectations of the users.
6. Maintenance: Includes regular upgrades for additional features, bug fixes, and operating system compatibility. Also includes on-going quality assurance tasks and customer support.
7. Obsolescence: Obsolescence plan insures there are pathways for users to move from the existing product to new products. In the case of a standard this insures the users can adopt a new standard if developed.
The deliverables for each of the phases are listed below. The deliverables are either documents or software. Each deliverable will be available on the web site.
In analyzing the use cases we recognized that there were different actions we could take to satisfy the users needs. Some of these actions included adding information to the protocol but others were satisfied by referring users to existing web sites and other tactics. The full list of options and when we would invoke each is below:
a. Do nothing
- Does not fall within our scope
- Someone else is doing it well
- Too complex or expensive
b. Build a centralized web site
- When the computing resources can be established
- When a single resource is needed for folks to access (i.e. a directory, a portal)
- When a centralized server is needed for caching data from providers
c. Link the user to the original source of the data
- When there is little value in aggregating the distributed data
d. Share the data through a protocol
- Data is and needs to be distributed (it is either too big, or data custodians want to maintain control and ownership). Requires tooling of data providers.
- When it is of general interest, support the most common queries (we only share a subset)
- Folks want to create derived products from the data (they have other computing resources)
- Folks want to build a portal to integrate data from multiple existing sources
Based on the number of definitions, this content has been moved to a separate definitions document.
Kruchten, P. 2000. The Rational Unified Process, An Introduction. Addison-Wesley, Reading, Massachusetts.
-- Main.AnnieSimpson - 04 Aug 2007 @