[CLIS logo]

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):

    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