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. |