LBSC 790/INFM 718B
Building the Human - Computer Interface
Fall 2004
Project Information
The goal of the project is to apply the rapid prototyping methodology
to develop an application with a significant amount of user interface
functionality. Students are required to work in teams of two, three
or four. Individual projects are not appropriate in this course and
will not normally be approved.
The focus of work outside of class will shift from the homework to the
project upon completion of the third homework assignment, so teams
must be formed by six weeks into the semester at the latest. An
earlier start on the project would, however, clearly be a good idea.
The basic idea is to complete three cycles of iterative specification
refinement, producing a working prototype in each cycle. The
objective of each cycle is to refine the specification, not to produce
the definitive implementation of the system, but the third iteration
should produce a prototype with a substantial amount of the important
functionality for your application fully implemented.
Two weeks are allowed for each iteration, which should provide
three-person teams with about 35 person-hours for specification and
implementation activity in each of the two-week periods. Teams should
be careful not to include more functionality in each iteration than
can reasonably be accomplished in this time frame unless they wish to
devote more time to the project than is required. Specifications and
working code should be turned in by 5:30 p.m. on the dates indicated
on the syllabus for the following
things:
First specification
Frozen prototype for spec 1, new spec 2
Frozen prototype for spec 2, new spec 3
Frozen prototype for spec 3, in-class demonstration
In order to encourage realistic planning and to remove possible
disincentives for attending class, late submissions will not be
accepted. With a two week period between iterations, a late
submission for one due date strongly resembles an early submission for
the next one. Specifications and frozen prototypes should be made
available as Java applets or applications through a project Web site
that you establish on WAM or any other convenient Web server, and
should remain unchanged for the entire semester. Teams should
probably allow several days prior to each due date (except the last
one) for preparing the next specification, so it would be wise to
freeze each prototype two days before it is due at the latest and move
on. This lesson has been learned the hard way -- no sense relearning
it again if you can avoid it.
Projects will be demonstrated in class during the last class of the
semester. Every member of the team will normally receive the same
project grade (exceptions can be made if all members of the team
propose an alternate grading strategy before the project begins), and
the project grade will account for a substantial portion of the grade
for the course (ash shown in the course
description. Individual specification and frozen prototype
iterations will not be graded separately. The following criteria will
be used when assigning project grades (in rough order of decreasing
importance):
- Timely submission of specifications and frozen prototypes
- The degree to which the progression between the prototypes
reflects an understanding of the rapid prototyping methodology
- The quality and clarity of each specification
- The degree of agreement between specifications and frozen
prototypes
- The degree of functionality incorporated in each prototype
It is possible to receive a good grade without building a system that
contains all the bells and whistles if the ultimate objective is
beyond that which could be achieved in three prototype iterations by a
team of the size you choose to form. But it will not be possible to
receive a good grade without applying the rapid prototyping
methodology well. If there are questions about where effort should be
focused you should discuss this with me early --- misspent effort is
not easily recovered.
Doug Oard
Last modified: Mon Jan 7 00:14:46 2002