The project this semester is to build an interface to an application system for graduate teaching assistantships in the computer science department. The GTA app system will have at least three views. The first will be a form that students fill out to apply for an assistantship. The other two will be for faculty and staff; one to view individual student applications, and the other to view a summary of all available applications.

The student information form must (at least) capture the following information: first name, last name, status at GMU (enrolled, applying, admitted), GMU student ID, mailing address, email address, phone numbers, the year and term the assistantship is requested (academic year, fall semester, spring semester, summer), information about previous GTAs held at GMU (when, department, supervisors, responsibilities), relevant classes and grades taken at GMU and elsewhere, previous work experience, interest and skills, date of birth, citizenship, country of citizenship and visa status (if non-USA), native language, TOEFL scores, and GRE scores. You may need to include other information as well.

The system must allow students to update and resubmit their own applications and must allow faculty and staff to modify applications and delete applications.

You have complete freedom to choose technologies and how the GTA app system will operate. You may choose to implement this project or suggest your own (see Alternative Project below). You are free to make as many assumptions and decisions as you like within these parameters. Be creative and have fun!

More freedom: You may deploy your system on any computer, and build your UI with any software support or package. Your interface may be of any style (GUI, Web-based, menu, command line). The important thing is that you follow the principles we discuss in class. You may use Unix computers, PCs, or Macintoshes, and you may use J2EE, PHP, Java, Motif, X, Powerbuilder, VisualBasic, HTML, or whatever is comfortable. For those who wish to use J2EE or PHP, I have arranged for accounts to be created on IT&E's J2EE application server, apps-swe632.ite.gmu.edu. If you wish to use a database, we can probably make arrangements to use the IT&E oracle server.

You are responsible for making your project available to me for a demo ... if I cannot access it, you will lose points. I must be able to see your project run on campus. You may make it available over the web, through the campus network, in a campus lab, or as a last option, bring a laptop to my office for a demo. I have a PC with Windows XP. I will not be able to accept installation software or otherwise install software on my computers; if you use a PC, you are responsible for finding a PC to show me or installing it on a PC in one of the labs. We will probably arrange for a dedicated PC in one of the IT&E labs at the end of the semester. You are also responsible for ensuring that any support software you need is available.

I encourage you to work with one partner, although you may also work alone. If you choose to work with a partner, the requirements will be the same, and I will expect each partner to submit a one page evaluation of the other partner at the end of the project. These evaluations may be used as part of your grade determination.

This project will have six milestones (as listed on the course schedule web page). Note that the first four are fairly small and not time consuming.

1. First you must submit a one page statement of intent that gives your name, your project, what development computer you plan to use, what deployment computer you plan to use, and what software you plan to use (HTML, CGI, Java, etc.). This is due February 10.
2. You will turn in a short user profile containing a description of the important characteristics of the users that you expect to use your system. This description should be based on the important characteristics of users that we discuss in class, including the three types of knowledge. Please refrain from including information about design; think of this as part of the requirements. Design will come later. This is due February 17.
3. You will submit a statement of interface goals, which will (1) describe user interface goals in terms of Shneiderman's five criteria, and (2) describe all the features you plan to implement in your system. The second part must define all information that you plan to request on the application form. Please refrain from including information about design; think of this as part of the requirements. Design will come later. This is due February 24.
4. You will complete and submit a simple demonstration interface using the same platform, implementation package, and interface style that your final project will use. The purpose of the technological demo is to ensure that you can use the software you plan to use and make it available to me. This is due March 24.
5. You will submit an initial interface screen design on paper—the screens and a description of the interaction. If the user profile describes a user who is significantly different from me, you may need to include task-semantic knowledge about the application so that I can evaluate your screens. You should also include comments on how the screens operate. This is due April 7.
6. Finally, you will turn in a short written report and either provide me with a location where I can evaluate your project or demo the project to me. The final report is due May 5 (the last day of class) if you install your software in a location that I can access by myself, or April 21 if an in-person demo is required. The 2-week earlier date for an in-person demo is because it takes time and effort to schedule the demos (and also to encourage you to avoid a demo if possible).

   The final short written report should include:

   1. Your name (and partner if you have one)
   2. A one or two sentence description of your project
   3. A paragraph describing the software you used to build your interface
   4. A short description of how I can use and run your project
   5. A short description of the software design
   6. Any notes or problems that I should be aware of (that is, things that don't work)

The project that I have suggested has the advantages of being small enough so that you can understand the system in a reasonably short time, being complex enough to present a reasonable interface challenge, and not requiring a lot of software underneath the interface. However, you may propose a different project, provided it is of a reasonable size (not too big, not too small). Note that you will not get credit for developing large amounts of software that is not part of an interface, and you will not get credit for learning new technology to build your interface.

For the next class, give me your project choice as a statement of intent. You should include your target hardware and operating system, and any support software package you intend to use. This does not have to be a long formal proposal ... please keep it brief, such as a list on one page.

© Jeff Offutt, 2000-2009, all rights reserved. This document is made available for use by GMU students of SWE 632. Copying, distribution or other use of this document without express permission of the author is forbidden. You may create links to pages in this web site, but may not copy all or part of the text without permission of the author.