Talisman Project

Members:

• Helen Huang
  
• Ross Knepper
  
• Carla Sereny
  
• Dan Singhal
  
• Jon Wildstrom
  

Planning Members [Summer 1997]:

• Ross Knepper
• Daniel Singhal

For most of this time period the team members engaged at Carnegie Mellon will be working on summer courses and other projects.

During this period I shall produce the documents necessary for properly planning and executing a project of this size. These documents will be the same as those used for CS3302 at Georgia Tech. They include:

Prelim			July 15
Schedule		July 20
Project Plan		[Not planned]
Requirements Document	July 30
Test Plan		August 10
Design Document		August 20
Configuration Mngt	August 30

1. The Preliminary Design will explain the broad level features and implementation of portions of the program. This submission will include a description of the game and how it works.
   
   
2. The Schedule will contain a brief description of what role each team member will play in the design and writing of the project. Every member is expected to act as a programmer, and each will likely have a secondary role to perform in conjunction with other team members. The schedule will also contain brief descriptions of the variuos sub-portions of the project, such as meetings, code and review, testing, and any details about any sub-portion.
   
   
3. At this time I am not planning to do a project plan except for the Preliminary Design.
   
   
4. The requirements document will be list and explain the features and capabilities the program and its parts are to have, how they are to interact with each other, and how they are to interact as a whole with the surrounding system. It will explain each feature in some detail, mapping portions of the game to clear and precise elements of the program and how they are to be determined as implemented. *
   
   
5. The test plan will cover each of the mappings made in the requirements document and map a test to each element. Each feature of the original game shall be mapped to have a test that will determine whether that feature works or not, The feature shall not be considered properly implemented until it has passed the tests set for it. *
   
   
6. The design document will consist of the layout of the parts and descriptions of their interactions. It will explicitly state what is to happen when an event occurs and will provide a clear idea of how events are to propagate through the system.
   
   
7. Configuration management will provide for a stabilized bed for testing elements at various stages. It will provide for a "last working version" that test cases can be run on to determine the working/not working of a new feature or element. It will also minimize the oppurtunities for multiple edits and lost changes, by allowing only single persons to work on an element or feature in one file.
   
   

The requirements document and test plans will be proposals, as their true effectivesness and accuracy cannot be measured until the project has begun and the design has been properly settled. The configuration management will be a description of what we are planning to do, and what we will be using to control it.

Each document will be sent for internal review amongst the team before it is submitted. The dates beside the titles represent planned dates of release for these documents.