Main Page
Title Page
Cover Letter
Individual Introductions
Executive Summary
Problem Statement
Requirements/Specifications
Cost/Benefit Analysis


 Risk Assessment
  The risks for our project mainly stem from how much we can get done in two semesters and specific issues that need to be worked out in our design. Since our program will be released under the GNU license and will be freely distributed, there aren't any real financial risks. We have to be realistic when estimating how far we can take the project and in so being, design the program so that new features can be added later if it will be expanded after this school year. When designing it we also have to worry about portability issues and how to make it so that the users will choose our product instead of one of the other Doc readers.
 
 
 Risks
 Mitigation
 We may find out we took on too much work for a two semester project.  In order to prevent biting off more than we can chew, we will follow our prioritized task list down as far as we can go. We will make sure we get all of the core features implemented, and design our program so that extra features can be easily added as time allows.
 Palm Computing® device users might not accept our Doc reader.  Since our program will be competing with several other Doc readers, we will have to make it good enough to be accepted by the users. We will keep the user interface simple and similar to other Palm Computing® platform programs. We will also consult with potential users like our sponsor, possibly demonstrating user interface prototypes.
 We might have to learn new platforms and the specific portability issues associated with them.  Each one of us will put the necessary time into learning the new platforms required for our project. We will learn how to use the development environment for the Palm operating system and the system dependent calls necessary for each platform.
 We might have to make several different versions of our program for different platforms.  To make our Doc reader portable to several platforms, and avoid making a different version for each, we will design our program with a layered architecture. We will stick to standards like POSIX and keep all the graphics and other platform specific code in library files that are easy to swap in and out when compiling for the different systems. The core of our program should be compatible with each platform.
 Additional features might be added that later seem obvious but that none of us thought to write down in the requirements.  We will use an incremental development method so that if additional features are added later we can go back and add them to our design before we add on to many layers to change the program. If it will take too much time to add a feature, we will reserve it for a second release if we have time to get to it.
 

Organization & Management
The Design/Development Process
Resources
Schedule
The Technical Concept
Screen Shots