Project Management Plan Template

Our project is to create a Cellular Automata simulation tool. The tool will be most likely used by computer scientists and biologists to create parameters that will simulate different life. Our Cellular Automata tool will give these researchers the ability to quickly change simulation parameters, and the flexibility to create very complex simulation conditions.

Reference Documents

Applicable Standards

Coding Standard: Our code will be well documented at the head of the file and throughout each file. Each version of the code will have it's date with it and version number. Code will have generous white space and all code blocks will be indented to provide for easier code reading. We will adopt a naming convention similar to the naming convention of the Java programming language. All classes will start with capitol letters, while functions will start with lower case letters. All classes will be in seperate files, and have documentation on the other classes (and the other class' version number) that they are compatible with.
Document Standard: All our non-code documents will be in the HTML format. The font size will be the default font size, with headings in boldface, and major headings in enlarged fonts. It will be decided later if we can perform spelling and grammer correction on our documents. In our opinion it's not critical on the documentation that is intended for development use only. The HTML format would provide major difficulties when the spelling and grammer is checked on a traditional word processor like Microsoft Word. The user manual will definitely be checked because it is a deliverable to the customer. All sizeable documents will have a table of contents and a modification history.
Artifact Size Metric Standard: Our metric for measuring the size of our code and progress will be to measure the size of the source code files in bytes. This metric will lessen the effects of whitespace (where as lines of could would increase) on our progress. This metric will not convey the complexity of the code, but it is quick, easy, and will fit our purposes.

Project Team Organization

Our group orgranization is pretty informal and pretty open. Since Jeff and Mike already knew each other before the class (and share all their classes this semester), this should not cause any problems. Michael is more of a leader and is always trying to create the greatest program the world has ever seen. Jeff is more relaxed and practical, which helps to keep the project more manageable.

Tasks will be divided between Mike and Jeff as they see fit during the process of the semester. We will avoid working on the same tasks at the same time to avoid redundancy. And the website will be kept up to date all the time on Pegasus with the latest version of each document created. This will avoid us having to coordinate with each other to bring the website together. We can communicate with each other daily, and intend to try to communicate with our customer every few weeks to keep him up to date on our progress.

Deliverables

Artifact	Due date(s)
Meeting Minutes	2 meetings to date
Individual Logs	These are updated each week and can be viewed any time by accessing our webpage on Pegasus.
Group Project Management Reports	T.B.A.
Concept of Operations	October 16, 2000
Project Management Plan	October 16, 2000
Software Requirement Specifications	October 23, 2000
High-Level Design	T.B.A.
Detailed Design	T.B.A.
Test Plan	T.B.A.
User's Manual	T.B.A.
Final Test Results	T.B.A.
Source, Executable, and Build Instructions	T.B.A.
Project Legacy	T.B.A.

Software Life Cycle Process

We are planning on beginning with prototyping our software, then the next step we intend to accomplish is to draw the UML diagrams for our system. This should help us find any features left out of the prototype that need to be included in the final product.

Tools and Computing Environment

We intend on using Java 2's JDK V1.3 to build our project. This will enable the product to run a variety of platforms, such as Windows 95 or later, Mac, Unix, or Solaris. The libraries that we will be using are the standard libraries that Java is distributed with.

Configuration Management

The version control of will be handled by each team member. Jeff and Mike are both responsible for updating the version number and recording any changes to a document when they are made. These changes will be recorded in table at the begining of each document.

Quality Assurance

Each team member will be responsible for quality assurance. The person responsible for drawing up a document will not be solely be responsible for checking the document for errors. Jeff and Mike will perform a walkthrough at the completion of each document, and inspections will be performed at key points in the development process. The results will be reported by each reviewer in a list, each list will contain items that the reviewer does not understand and items that the reviewer believes are incorrect.

Risk Management

Learning curve: There is alot of new Java aspects Jeff and Mike have to learn to make this project succesful. Jeff had some experience with the Java Swing GUI components, but Mike has never used them. We have to make sure we learn all the skills we need, and we need to learn them all in time to finish the project.
Customer expectations: Our grade depends on the customer's satisfaction with the project. We need to make sure that our program fits Dr. Moshell's needs and requirements.
Time: Our biggest challenge in completing this project will be finding the time to work on the project. Between school, work, homework, and social activities there is very little time left for anything.

Table of Work Packages, Time Estimates, and Assignments

Work package Estimated Time Responsiblity

Documentation 30 hours Jeff and Mike

Webpages 10 hours Jeff and Mike

Coding 40 hours Jeff and Mike

PERT Chart

Pert Chart
Pert Chart for Project Management Plan Version 1.0

Our critical path is: (5 weeks) Main simulation window -> Procedures for inital state editing -> Help utility for entire simulation

Technical Progress Metrics

Requirements phase:
- Number of requirements = ?
- Number of requirement changes = ?
Object-oriented analysis phase:
- Number of UML diagrams completed = 0
Object-oriented design phase:
Object-oriented programming phase:
<You must estimate and track your technical progress using appropriate metrics for each phase of your project. What is a useful metric for each phase of your project? For example, for requirements phase, the total number of requirements, the number of requirements changes, the number of TBDs, ... For OO analysis and design, you might want to count UML diagrams completed. For detailed design and code, you might want to count packages, classes, methods. You will also want to think about other technical metrics such as: memory usage, execution speed, size of various documents, complexity of code (using any of the complexity metrics), ... These can help in planning and in tracking your project work.>

<Choose your metrics carefully -- select metrics that will be easy to collect, easy to report, and easy to interpret. The goal is to give management insight into the progress and risks of your project.>

Plan for tracking, control, and reporting of progress

Each team member is repsonsible for updating their own webpage weekly. Which includes individual time log, individual status information, individual issues and problems, and individual defect log.

Every two weeks the group will meet to perform an informal review in which any changes or questions reguarding the project will be discussed. At this meeting the project mangement report will be updated to include the latest information on the project progress. This will included updating the actual time versus the planned time.

Template created by G. Walton ( GWalton@mail.ucf.edu ) on Aug 30, 1999 and last updated Aug 15, 2000.

This page last modified by Jeff Miller ( j_miller68@hotmail.com ) on October 15, 2000.

Work package	Estimated Time	Responsiblity
Documentation	30 hours	Jeff and Mike
Webpages	10 hours	Jeff and Mike
Coding	40 hours	Jeff and Mike

Informal Science Education II Project Management Plan EEL 5881 - Software Engineering, Fall 2000

Contents of this Document

Informal Science Education II

Project Management Plan

EEL 5881 - Software Engineering, Fall 2000