Download Project Development Plan

Table Of Contents
Executive Summary
The project development plan covers team Circuitscape's plans and schedule for developing the
Circuitscape Gene Flow Simulator, which models the genetic difference between two
geographically distant groups of creatures. An analysis of technological, skills, and personnel
risks is included, followed by plans for capturing, revising, and tracking requirements. We also
provide a listing of design documents the client will receive, a review of how the spiral
development model will be used, and a Gantt chart showing the planned development schedule.
Plans for tracking version numbers and integrating team code are discussed, system requirements
for the planned software are shown, as are plans for keeping the client informed of progress on
the project.
Table of Contents
1. General Info
2. Organization, Responsibilities and Authorities of the Team
3. Risk Areas
4. Requirements
5. Design Documentation to be Delivered
6. Development Process and Preliminary Schedule
7. Software Configuration Management Plan
8. Hardware and Platforms Used for Development
9. Keeping the Client Informed
1
p.2,p.3
p.3
p.3,p.4,p.5,p.6
p.6,p.7
p.7
p.7,p.8,attachment
p.8
p.8
p.9
1
General Info
1.1
Overview
Brad McRae came to team Circuitscape on January 21, 2004 to design a new Circuitscape
program. This program uses circuit theory to model gene flow.
Gene flow theory is the study of the flow of genetic material from one creature population to
another, and of the genetic difference between geographically distant populations. It can be used
to study the health of a population and the effects of terrain on animal populations.
Brad McRae, a researcher in the NAU Forestry department, has pioneered the use of circuit
theory to model gene flow because of deficiencies in existing modeling techniques, including
Markov Chain Theory and the geographical distance model.
Consider an example gene flow problem. There is an area of terrain occupied by various groups
of mountain lions. This area's map can be approximated by a 500x500 pixel grid. We want to
know how much migration there is between two groups of mountain lions in this area so we can
see if they are receiving a healthy amount of genetic material from each other (i.e. we want to be
sure they are not in-breeding).
Suppose we try analyzing the flow of genes in the mountain lion example using the geographical
distance model. The model can make an approximation of the gene flow occurring, but it is a
poor one because only the distance between the groups is accounted for. All geographical
features are ignored. Thus, the geographical distance model can be used here but its inaccuracy
means the information obtained is low-quality. The geographical distance model fails to simulate
the effects of a heterogeneous landscape by not accounting for geographical features like barriers
to genetic movement (e.g. the area of land between two lakes when considering fish migration).
On the other hand, models based on Markov Chain Theory are accurate but computationally
expensive. Only small data sets can be modeled without exceeding the capabilities of most
personal computers. Consider using Markov Chain Theory to analyze our example. Because the
map involved is so large, we will need a computer to do the computations. Markov Chain Theory
is very accurate, so the information produced from this analysis will be high-quality. However,
after entering the data into the model and starting the Markov program, the computer crashes!
Markov Chain Theory uses so much memory it could not handle a matrix even a tenth the size of
ours.
How would resistor field theory work for analyzing the mountain lion example? We enter the
array of map data into the program, and run it. The program executes without problems, and
produces results much more accurate than the geographic distance model and almost as accurate
as the Markov Chain Theory approach. The use of resistor field theory as a basis for gene flow
modeling promises to produce accurate models for large sets of data.
There is currently a program implementing resistor field theory, but it has several problems:

It is written for Matlab, an expensive and complex mathematics program

The user interface is a command line with little tolerance for error

There is no user help included in the program
2

The code is un-commented and difficult to understand
Team Circuitscape's task is to write a new version of the Circuitscape program. The program will
allow users to calculate the effects of terrain on the flow of genes between animal populations. It
will have several features:

Can be used to find migration rates between two groups of creatures

Produces output viewable in Excel

Uses a more common programming language allowing its downloaded and used by the
average person

Mathematical capabilities of the program will be expanded to create a better model

A graphical user interface that allows more natural data entry and control

In-program help system

Well-documented code for easier updating
1.2
Document References
Readers may find it useful to read Integrating Landscape Ecology and Popular Genetics: New
Tools From Circuit Theory. This article describes how circuit theory can be used in genetics,
why it is useful, and some examples of the mathematics involved.
2 Organization, Responsibilities and Authorities of the Team

Michael Schulte, Coordinator - responsible for initiating coordinating interaction with the
client.

Kathleen Rankin, Recorder, Notebook Keeper - responsible for recording team tasks and
activities along with keeping the team notebook up to date.

Sean Collins, Leader, Webmaster - responsible for overall coordination of the team and
keeping the team website up to date.

Carl Reniker, Facilitator - responsible for moderating disputes within the team and ensuring
orderly team meetings.
3 Risk Areas
Risks will be given a ranking on severity and likelihood using a qualitative scale: very high,
high, moderate, low, very low.
3.1
Technological Risks
Risks associated with the technology used by the software.
3.1.1
Memory Problems
Severity
high
Likelihood
moderate
Description
The software may need to handle very
large data sets, which will lead to high
memory consumption. If the program
needs more memory than the machine
can muster, problems will occur.
Monitoring Plan
The program will be tested with large
data sets. There is a problem if the
3
Mitigation Strategy
computer running the program runs out
of memory.
Set an upper limit on data set sizes.
Analyze the code of the program for
unnecessarily high memory consumption
and optimize it. If this is not enough, set
a higher upper limit on the size of data
sets allowed.
3.2
Skills Risks
These risks arise from lack of a needed skill on the part of the team.
3.2.1
Problems Understanding Complex
Mathematics
Severity
very high
Likelihood
low
Description
The software needs to find the genetic
difference between populations. This is
done using the mathematical technique
of nodal analysis. Without a proper
understanding of the math needed, the
whole project will be useless.
Monitoring Plan
The team will read through the code
currently written for Matlab to check
understanding. If any part of the math is
confusing, team members will try to
figure it out with pencil and paper. If
they fail to reach understanding in this
way, there is a problem.
Mitigation Strategy
Immediately contact the sponsor and ask
for an explanation of the problem area.
3.2.2
Severity
Likelihood
Description
Monitoring Plan
Mitigation Strategy
4
Translating Matlab to Java
low
high
The program currently used for circuit
gene flow theory is for Matlab, and
needs to be translated to Java. The team
has had no experience with Matlab
before this project, and may encounter
difficulty understanding the Matlab
code.
The team will read the Matlab code and
try to understand what it is doing. If an
unknown language element is found, the
problem has been encountered.
If at any point an unknown language
element is encountered, its purpose will
be researched online and using any other
immediately available resources. If this
does not solve the problem, the sponsor
will be contacted with a question about
the language problem encountered.
3.3
Personnel Risks
Risks that come from problems with team members.
3.3.1
A Team Member is Lost
Severity
high
Likelihood
very low
Description
A member of the team leaves the class,
leaving fewer people to complete the
project.
Monitoring Plan
Watch for attendance at meetings. If a
team member misses one and fails to
contact the team, the member is
contacted. If they say they left the class,
the problem has occurred.
Mitigation Strategy
Redistribute work assigned to the
missing member to the remaining team
members.
3.3.2
Severity
Likelihood
Description
Monitoring Plan
Mitigation Strategy
A Team Member Becomes Lax In Their
Duties
moderate
moderate
A member of the team begins to
consistently perform below expectations.
Check performance of team members on
assignments. There is a problem if the
team member consistently performs
below expectations and/or is
uncooperative about their work.
Tell the team member to improve their
work. If this is ineffective, consult the
project manager.
4 Requirements
4.1
Capturing the Primary Requirements
The primary requirements will be obtained from the requirements the sponsor has listed on the
project description on the capstone website, from the handouts he has provided to the team, and
from verbal questioning about the requirements. The primary requirements will be recorded in
the requirements document. They will be labeled using decimal notation and they will have a
description and a listing of all sub-requirements. These requirements will then be shown to the
sponsor, who is free to make all changes he feels necessary.
5
4.2
Showing Derived Requirements
Derived requirements will be listed in revised versions of the requirements document, under the
headings of previous requirements to which they apply or under new headings, as appropriate.
They will state which requirement they were derived from in their description. Each derived
requirement will be brought before the client for verification before it becomes an official part of
the project.
4.3
Tracking Requirements to the Architecture
The architecture will be outlined in the software design specification. UML diagrams in the
specification will be labeled with the number of the requirement that each component of the
software satisfies.
4.4
Tracking Requirements to the Design and Implementation
Each method and object in the code will be labeled in a header comment with the number of the
requirement they help satisfy.
4.5
Examples of How Requirements Are Shown in Documentation
Capturing the Primary Requirements
Showing Derived Requirements
Tracking Requirements to the
Architecture
Tracking Requirements to the Design
and Implementation
5





1 Main Requirement Description
1.1 Sub-requirement Description
4 Derived Requirement Description
derived from requirement 3
Class Car
(Satisfies Requirement 1.2)
/*Satisfies requirement number 1.1 of
the requirements document*/
Design Documentation to be Delivered
Requirements document: on due date at 2/18 and every time a significant change is made
(i.e. a change to the requirements)
Weekly status report: every week on Friday
Website Information: updated every time new content is needed
Screen Shots of the Program: with the weekly status report when necessary
Print-outs of Program Output: whenever necessary
6
Development Process and Preliminary Schedule
6.1
Development Process
The team will use the spiral model to guide the development process.
This involves several steps:
1. Planning the project then doing risk analysis
2. Producing a prototype
3. Submitting the prototype to the client for review
6
4. Redefine the requirements for the next prototype
The steps of planning, risk analysis, prototyping, and client review are repeated, followed by
another re-definition of requirements. This process is repeated until the desired product is
created.
Since the requirements break up cleanly into parts that can be developed sequentially in different
modules, the team can fit these modules into the spiral development model as successive
additions to prototypes. These modules will be the milestones: first the primary requirements
prototype, then performance requirements are added, then secondary requirements, then tertiary
requirements.
6.2
Schedule
See attached Gantt chart.
7
Software Configuration Management Plan
7.1
IDEs
The only IDE the team plans on using is Eclipse for Java.
7.2
Version Control
Each time a piece of code is modified it is given a version number, which is part of the file name.
Version numbers also go at the top of code in the comments, with all major changes and dates of
the changes listed. Versions start out at one, and are incremented by one for each new version.
Each version is saved without over-writing older versions so it is possible to roll the version back
in case of problems.
7.3
Integration of Individual Efforts
The project will be saved in a shared directory (the team will find out where exactly before
implementation begins). The shared directory will contain individual directories for each team
member labeled with their first names, with a directory for new code, called new, and a directory
for old code, called old, in these individual directories. All older versions of each team member's
code will be in the old directory and the newest version will be in the new directory. Every team
member will only work on code assigned to them. When a team member wishes to change
another's code, they must get permission.
The code for the entire program will be in a separate folder named project. Inside this folder will
be a folder called old and a folder called new, where the older versions and the newest version of
the code is stored, respectively. Team members will collaborate on code integration to assure it is
done correctly, storing the result in the new folder and moving the previous version to the old
folder.
8
Hardware and Platforms Used for Development
The software will be developed for use on Windows 98/2000/XP machines with 400 MHz
Pentium III processors and 128MB RAM. Software used in development will be Matlab, the
Java SDK, and Eclipse.
7
9
Keeping the Client Informed
The client will be kept up-to-date on the progress of the project through the documents
mentioned in the Design Documentation to be Delivered section. Additionally, the client will
receive working prototypes of the code for each milestone, which includes primary,
performance, secondary, and completion. If needed, more communication will be done with the
client via e-mail whenever necessary.
8