140 lines
7.7 KiB
Plaintext
140 lines
7.7 KiB
Plaintext
head 1.1;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.1
|
|
date 2007.08.04.03.51.25; author AnnieSimpson; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="AnnieSimpson" date="1186199485" format="1.1" reprev="1.1" version="1.1"}%
|
|
%META:TOPICPARENT{name="DevelopmentDocsGISIN"}%
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
|
|
<title>GISIN: Overall Plan</title>
|
|
<link rel='stylesheet' href='W3C-REC.css' type='text/css'>
|
|
</head>
|
|
|
|
<body>
|
|
<h1>Overall Plan</h1>
|
|
|
|
<h4>Version: 1.2 -- OverallPlanGISIN</h4>
|
|
<h4>Last Update: 7th of November, 2006</h4>
|
|
|
|
<h2>1. Introduction</h2>
|
|
<p>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).</p>
|
|
<p>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. </p>
|
|
<h2>2. Lifecycle</h2>
|
|
<p>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).</p>
|
|
<p>The software lifecycle breaks the development process into the following steps:</p>
|
|
<p>1. Investigation: Determine user needs, technical feasibility, and available alternatives for implementation<br />
|
|
2. Design: Create the design for the system to be implemented. This typically includes object-oriented design techniques and prototyping to investigate design issues.<br />
|
|
3. Implementation: Writing of the final software. For a standard this typically includes the toolkits provided to users and test tools.<br />
|
|
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.<br />
|
|
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.<br />
|
|
6. Maintenance: Includes regular upgrades for additional features, bug fixes, and operating system compatibility. Also includes on-going quality assurance tasks and customer support.<br />
|
|
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.</p>
|
|
<p>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.</p>
|
|
|
|
<h3>2.1 Investigation</h3>
|
|
<ul type="disc">
|
|
<li>User interview/investigation results</li>
|
|
<li>Use cases – what users need to be able to do</li>
|
|
<li>Requirements specification – defines what needs to be created</li>
|
|
<li>Feasibility studies – make sure we can do it</li>
|
|
<li>Alternatives analysis – select the best implementation approach given all the requirements</li>
|
|
<li>Investigate existing solutions and pick from them what can be used.</li>
|
|
</ul>
|
|
<h3>2.2 Design</h3>
|
|
<ul type="disc">
|
|
<li>Schema specification – definition of the structure of the data</li>
|
|
<li>Protocol specification – how the data will be communicated</li>
|
|
<li>Toolkit design specification – software and documentation for providers</li>
|
|
</ul>
|
|
<h3>2.3 Implementation</h3>
|
|
<ul type="disc">
|
|
<li>Toolkits – documentation and software to aid providers in joining the system</li>
|
|
</ul>
|
|
<h3>2.4 Quality assurance</h3>
|
|
<ul type="disc">
|
|
<li>Test plan – how we will test to insure requirements are met</li>
|
|
<li>Test tools – software tools to test the toolkits and the system </li>
|
|
</ul>
|
|
<h3>2.5 Delivery</h3>
|
|
<ul type="disc">
|
|
<li>Introduction plan – how the system will be introduced</li>
|
|
</ul>
|
|
<h3>2.6 Maintenance</h3>
|
|
<ul type="disc">
|
|
<li>Upgrade plan – how we will develop, test, deliver upgrades</li>
|
|
<li>Customer support plan – how we will provide support to providers (email, phones, etc.)</li>
|
|
</ul>
|
|
<h3>2.7 Obsolescence</h3>
|
|
<ul type="disc">
|
|
<li>Obsolescence plan</li>
|
|
</ul>
|
|
|
|
<h2>3. Use Case Analysis</h2>
|
|
<p>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:</p>
|
|
<p>a. Do nothing<br />
|
|
- Does not fall within our scope<br />
|
|
- Someone else is doing it well<br />
|
|
- Too complex or expensive<br />
|
|
b. Build a centralized web site<br />
|
|
- When the computing resources can be established <br />
|
|
- When a single resource is needed for folks to access (i.e. a directory, a portal)<br />
|
|
- When a centralized server is needed for caching data from providers<br />
|
|
c. Link the user to the original source of the data<br />
|
|
- When there is little value in aggregating the distributed data<br />
|
|
d. Share the data through a protocol<br />
|
|
- 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.<br />
|
|
- When it is of general interest, support the most common queries (we only share a subset) <br />
|
|
- Folks want to create derived products from the data (they have other computing resources)<br />
|
|
- Folks want to build a portal to integrate data from multiple existing sources</p>
|
|
|
|
<h2>4. Definitions</h2>
|
|
<p>Based on the number of definitions, this content has been moved to a separate <a href="Definitions.html">definitions document</a>. </p>
|
|
|
|
<h2>Appendix A – Issues</h2>
|
|
<h3>A.1 Are we extending an existing system or building a new one?</h3>
|
|
- We are adding the required information to existing standards to meet the needs of the invasive species community.</p>
|
|
<h3>A.2 Which sources?</h3>
|
|
- Anyone with invasive species data and the ability to host it on a web server?</p>
|
|
<h3>A.3 How will the group communicate?</h3>
|
|
- Email for now<br />
|
|
- Conferences when possible<br />
|
|
- WiKis?<br />
|
|
- GISIN Web site?</p>
|
|
<h3>A.4 What types of data are we interested in?</h3>
|
|
- Access databases, enterprise level databases, etc.<br />
|
|
- Occurrence data, negative data (absence data), checklists, bio-status</p>
|
|
<h3>A.5 What types of data are we not interested in?</h3>
|
|
- Paper. There are other groups working on the digitization of paper data</p>
|
|
|
|
<h2>Appendix B - References</h2>
|
|
<p>Kruchten, P. 2000. The Rational Unified Process, An Introduction. Addison-Wesley, Reading, Massachusetts.</p>
|
|
</body>
|
|
</html>
|
|
|
|
|
|
|
|
|
|
-- Main.AnnieSimpson - 04 Aug 2007
|
|
@
|