Steam-powered Turing Machine University of Washington Department of Computer Science & Engineering
 CSE574 Project Description
  CSE Home   About Us    Search    Contact Info 

Administrivia
 Home
 Using course email
 Email archive
 Policies
Content
 Reading Wiki
 Resources
 Lecture slides
Assignments
 Reading Reports
 Term Project
   

Scale

Projects may be individual or done in small groups (2 to 4 students).

Topic

Any topic is acceptable so long as it is related to the course topics. Specifically, while programming-oriented projects are recommended, literature reviews or other 'report oriented' projects may be acceptable as well. Furthermore, if you are already working on a relevant project (e.g. quals or thesis) check with Dan, since work on it may well count for the project component.

It is highly recommended that you meet with or email Dan a description of hwat you are interested in doing soon to get the discussion going. Even a short paragraph suffices to start the conversation rolling.

Ideas

Click here for some ideas of possible projects.

Proposals

Click here for the proposals you submitted..

The ideal proposal would
  1. Be written in HTML and delivered as a URL which I could link to on the class site. You can then update it as time progresses.

  2. State clearly the problem you are addressing and what you hope to create as an artifact. Technically, you could satisfy this requirement with a single sentence (and some groups did with the preproposal), but this time I'm looking for much greater detail. If your project has a big UI component, can you include a figure showing what it might look like? Can you include an architectural diagram? The more detail the better, and of course you can change your minds later.

  3. Break the project's development into (much) smaller chunks. Describe each chunk thoroughly. What dependencies are there between the pieces? Can you connect the overall project as a linked schedule or pert chart? Estimate the estimate the time required to develop each chunk and sum up the total time along critical paths. If your group has multiple people, who will work on each chunk?

    Most likely, these plans will change as time evolves, but it is a very useful exercise to plan it out anyway.

  4. Describe the series of milestones you expect to pass as a way of us each being able to monitor progress. I've previously said "2 week intervals", but unless there's substantially some better schedule, let's standardize on the following dates:
    • Jan 30 - proposal due
    • Feb 13 - milestone 1 due
    • Feb 27 - milestone 2 due
    • Mar 12 and 14 - project presentations, demos, etc.
    • Mar 21, no exam - instead reports are due via email by midnight.

  5. List and third-party software you think you might use.

  6. If machine learning is involved in your project, describe where you'll get your training (and testing) data

  7. Explain how you will evaluate success. What will you measure, how will you measure it, how will you display it in the final report? (graphs are usually better than tables if you can think of a good way to visualize the data)

Guidelines for Final Presentations

  • Length: TBD
    Be sure to practice presentation & gauge length
  • Powerpoint or PDF Slides (Max 10)
    Mail to me by 11am on day of presentation unless you will bring your own laptop.
  • Every team member should talk for some of the slot
  • Subtopics to cover:
    • Aspirations & reality of what you built
    • Demo?
    • Suprises (What was harder or easier than expected)
    • What did you learn?
    • Experiments & validation
    • Who did what

Guidelines for Final Reports

Be sure that your writeup contains:
  • Team and member names (one report per group).
  • Your goals for the project
  • Your system design and algorithmic choices
  • Sample screens of typical usage scenarios
  • Experiments and results that show how effective your system is, and where it could be improved. For example, you might show a precision / recall curve for different types of extraction algorithms. Graphs (if informative) are better than large tables of numbers. See some of the papers in the reading. The Kylin paper is not particularly unusual in this respect, but may give you ideas.
  • Anything you considered suprising or that you learned. WHat would you do differently if you could?
  • Conclusions and ideas for future work
  • Appendicies:
    • Which people did what parts of the work? Were there problematic dynamics in your group?
    • What externally-written code (if any) was used in your project?
    • Instructions on how to start and use your project (including OS or browser requirements, pointer to a README file (or include that inline). Is there a website to visit?
There is no limit on length, but we appreciate good organization and tight, precise writing. Points off for rambling and repetition.

What to Hand In:

  • By midnight on March 21, please hand in a hard-copy of your report as well as an electronic version of both the report and the code. We will supply details on the electronic hand-in process via the class mailing list.
  • Late submissions for the final project and writeup will not be accepted, as it will be the end of the quarter. Sorry! (But happy holidays).


CSE logo Department of Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA  98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX