LANDIS-II v6

Overall Goals

1. Simplify LANDIS-II management. We must assume that money will not be available for a full-time programmer and most of the ongoing maintenance will be performed by scientists or undergraduates. This dictates a premium on documentation and simplification.
2. Simplify extension programming. With v5.x, we generally failed to build a robust and active extension developer community. This is largely because we failed to understand the challenges for scientists who want to modify our code. We will therefore simplify extension programming through the architecture and the supporting tools. For example, we will move the cohort libraries out of the core in order to simplify programming to a large degree.
3. Incorporate GDAL. We MUST implement the Geospatial Data Abstract Library. We will sacrifice backwards compatibility with the ERDAS 7.4 format if necessary to do so.
4. Improve/update documentation. Developer documentation for the core will need to be updated.
5. Improve the user experience. A few (relatively) simple tweaks to the input format could significantly improve the user experience. One example is the pre-verification of all inputs files before program initiation.
6. Update extensions to work with v6.0. Every extension will need updating.
7. Replace our NAnt project files used to build core, libraries, and extensions. We need to find an alternative that will enable external developers to use IDEs on Windows and OS X to work on the same extension.
8. Develop user widgets. We acknowledge that LIME was not ready for release and there was no budget to support it. Instead, we will focus on developing small tools (widgets) including: Scenario Launcher, Scenario Builder, others TBD.

Important Components

• Unified Process - The process we're using to build LANDIS-II v6.0.
• Project Risks - The risks and uncertainties for the development of LANDIS-II.
• v6 Features and To Do List - The features expected for v6.0.

Project Phases

• Completion date: September 2010

Inception Phase:

The purpose of this phase is to establish a common vision, by defining the project's scope.

• Iteration 0 - Identify the project goals and their priorities.
  Completed December 16-17, 2009

Elaboration Phase:

The purpose of this phase is to capture most of the project's requirements, develop the system's architecture, and mitigate significant risks.

• Iteration 1 - Revise to-do list, begin assembling student projects, examine legacy code.
  Completed: January 27, 2010 -- Assessment
• Iteration 2 - GDAL implementation, student infrastructure.
  Completed: March 17, 2010 -- Assessment
• Iteration 3 - GDAL integration, hiring students.
  Completed: April 21, 2010 -- Assessment
• Iteration 4 - Further GDAL work, Utility work, solution/project files, remove cohorts from the Core.
  Completed: May 20, 2010 -- Assessment
• Iteration 5 - Remove cohorts from the Core.
  Completed: June 21, 2010 -- Assessment

Construction Phase:

The purpose of this phase is to build the remaining parts of the system, resulting in an initial operational release to users for beta testing.

• Iteration 6 - Test new Core without Cohorts. Complete PlugIn, Spp, Ecoregions, Main.
  Completed: July 13, 2010
• Iteration 7 - Refactor Succession. User Widgets.
  To Be Completed: August 3, 2010

Transition Phase:

The purpose of this phase to address issues identified by beta and acceptance testing, and to prepare the system for final release to users.