The purpose of this Software Development Plan is to define the development activities in terms of the phases and iterations required for implementing the Campbell Prediction System (CPS).

Scope

This Software Development Plan describes the overall plan to be used by the Campbell Prediction System project, including deployment of the product. The details of the individual iterations will be described in the Iteration Plans.

The plans as outlined in this document are based upon the product requirements as defined in the Vision Document.

Definitions, Acronyms, and Abbreviations

CPS: Campbell Prediction System

Also, see the Project Glossary.

References

For the Software Development Plan, the list of referenced artifacts includes--

The Campbell Prediction System, 1991, Doug Campbell
Vision Document
Software Requirements Specification
Release Notes
Glossary
Development Case
Programming Guidelines

Overview

This Software Development Plan contains the following information:

Project Overview — provides a description of the project's purpose, scope, and objectives. It also defines the deliverables that the project is expected to deliver.
Project Organization — describes the organizational structure of the project team.
Management Process — defines the major phases and milestones for the project, and describes how the project will be monitored.
Applicable Plans and Guidelines — provides an overview of the software development process, including methods, tools and techniques to be followed.

Project Overview

Project Purpose, Scope, and Objectives

This project will implement a training tool and decision support system based on the Campbell Predition System methods to compute, project and visualize the potential fire behavior, trigger points and alignments-of-forces on the fireground. See the Vision Document for an expanded description.

Assumptions and Constraints

Staffing: Constrained the principle software architect, developer and manager. Additional open source contributors are welcome, but are not assumed.

Budget: Personally financed

Schedule: Not a driver (yet). Development efforts are constrained by "day-jobs".

Project Deliverables

Following is a list of the artifacts to be created during the project. Deliverables are delivered towards the end of the iteration, as specified in the Project Schedule section.

Inception Phase Artifacts

Vision Document
Software Requirements Specification
- Use Case Diagrams
- Requirements Diagrams
Software Development Plan
Development Case
CPS "proof-of-concept" prototype
Release Notes

Elaboration Phase Artifacts

Software Requirements Specification - refined
Software Architecture Document
Software Development Plan - updated
CPS evolutionary prototype
Release Notes - updated

Evolution of the Software Development Plan

The Software Development Plan will be revised prior to the start of each iteration. The target dates are shown below.

Version	Phase	Target Date
0.x	Inception	October 2009
1.1	Elaboration Iteration 1	December 2009
1.2	Elaboration Iteration 2	January 2009
2.1	Construction Iteration 1	February 2010
2.2	Construction Iteration 2	April 2010
2.n	Construction Iteration n	TBD 2010
3	Transition	TBD 2010

Project Organization

Organizational Structure

The project team is organized as follows:

Bruce Schubert: Project Manager; Software Architect; Designer and Lead Developer

Doug Campbell -- Author of The Campbell Prediction System, Fire Behavior Analyst: Stakeholder and CPS Domain Expert; Course Developer

External Interfaces

External groups include:

CPS Instructors
Fire Departments

The primary interface with external groups is through the CPS Discussion Forums and CPS Mailing lists hosted at Project Kenai (http://cps.kenai.com).

Roles and Responsibilities

The following table shows the roles represented in the project diagram above and their primary responsibilities.

Role	Responsibility
Project Manager	The project manager role allocates resources, shapes priorities, coordinates interactions with customers and users, and generally keeps the project team focused on the right goal. The project manager also establishes a set of practices that ensure the integrity and quality of project artifacts.
Software Architect	The software architect role leads and coordinates technical activities and artifacts throughout the project. The software architect's view is one of breadth as opposed to one of depth.
Designer	The designer role defines the responsibilities, operations, attributes, and relationships of one or several classes, and determines how they will be adjusted to the implementation environment.
Technical Writer	The technical writer produces end-user support material such as user guides, help texts, release notes, and so on.
Course Developer	The course developer develops training material to teach users how to use the product. This includes creating slides, student notes, examples, tutorials, and so on to enhance users' understanding of the product.
Stakeholder	The stakeholder role is defined as anyone who is materially affected by the outcome of the project. Typically, stakeholders will have different perspectives on the problem and different needs that must be addressed by the solution.

Management Process

Project Estimates

Due to the volatility of developer schedules, calendar estimates are nearly impossible to pin down.

Project Plan

Project tasks can be viewed as follows:

Task	Start	End
Initial Project Charter	May 4, 2008	May 4, 2008
Inception Phase
Develop Proof of Concept	Aug. 2009	Sep. 24, 2009
Setup Project Kenai website	Aug. 21, 2009	Aug. 26, 2009
Setup Emxsys website	Sep. 4, 2009	Sep.7, 2009
Setup Emxsys website	Sep. 4, 2009	Sep.7, 2009
Develop proof-of-concept prototype (public)	Aug. 2009	Sep. 24, 2009
Develop proof-of-concept RCP prototype (internal)	Late Sep. 2009	Mid Oct. 2009
Create/update software development artifacts and website	Late Oct. 2009	Nov. 7, 2009
Milestone - Iteration Phase Complete	Nov. 7, 2009	Nov. 7, 2009
Elaboration Phase
Develop Software Architecture Document	Nov. 9, 2009	Nov. 15, 2009
Develop NetBeans RCP prototype	Nov. 9, 2009	Nov. 15, 2009
Construction Phase

Transition Phase

Phase Plan

The development of the will be conducted using a phased approach where multiple iterations occur within a phase. The phases and the relative timeline is shown in the table below.

Phase	No. of Iterations	Duration
Inception Phase	1	6 Weeks
Elaboration Phase	2	8 Weeks
Construction Phase	TBD	TBD
Transition Phase	TBD	TBD

Iteration Objectives

The following table lists the objectives to be accomplished for each of the iterations. Iterations are identified by a letter number combination:

Iteration	Objectives
Inception Phase
I1	Proof-of-Concept prototype Behave output 3D Terrain Rendering
Elaboration Phase
E1	Evolutionary prototype: NetBeans RCP architecture Behave output to include Solar Preheating
E2	Evolutionary prototype: Behave calculations to use LANDFIRE data
Construction Phase
C1	TBD
Transition Phase
T1	TBD

Releases

A brief description of each software release and whether it’s demo, beta, and so on...

CPS 0.4.0: RCP prototype, internal

CPS 0.3.0: NASA WorldWind, alpha, public

CPS 0.2.1: Bug fixes, alpha, public

CPS 0.2.0: alpha release

CPS 0.1.0: alpha release

Project Schedule

[Diagrams or tables showing target dates for completion of iterations and phases, release points, demos, and other milestones.]

Project Resourcing

[Identify the numbers and type of staff required here, including any special skills or experience, scheduled by project phase or iteration.]

Project Monitoring and Control

Configuration Management: Subversion, JIRA

Problem Resolution: TBD

Open-Source Contibutions: TBD.

Process Improvement Plan: "Lessons Learned' will be captured in a FAQ style Wiki page to hopefully prevent others from solving the same problems again and again.

Annexes

The project will follow the RUP for Small Projects process -- influenced by Agile methodologies --as tailored by the project Development Case.

Other applicable process plans are listed in the references section, including Programming Guidelines.