Due: pairs by Tuesday, January 10, 11:59
Due: proposal documents by Wednesday, January 11, 23:59, via Canvas
Due: presentations in class on Thursday, January 12
Due: project preferences by Friday, January 13, 16:59
The goal of this assignment is to develop great ideas about how to improve software development or maintenance. You are allowed to propose whatever project you think is interesting and valuable, which will improve the lives of software professionals. You will pitch your idea, together with your partner, in hopes of getting your project approved and attracting other team members to your project.
The staff has written up some project ideas. Please read them. You are free to use them, and any one of them would make a great project. You can also propose your own project; that is equally good.
This assignment must be completed in groups of 2. You should have determined your group by Tuesday after class, at the very latest (but preferably before then). If you need a partner, send mail to the class mailing list. There is nothing to submit for this part.
You will produce two deliverables for this assignment:
For anything that you submit in this class, place partners' names and UW net IDs on the first page (or first slide).
You will submit both deliverables electronically, in PDF. Each deliverable should include at least one figure or diagram (possibly the same, possibly different).
The files you submit should be
named student1-student2-doc.pdf and
student1-student2-slides.pdf (where the
student1 part is your UW net ID), and exactly one member of the team should actually submit these files.
The two deliverables should address similar issues, though they should do so in different ways, since different formats demand different ways of conveying the same information. You should discuss your vision, your proposed approach, and risks. Some of the points you should address include the following. This is not an exhaustive list; we expect you to think in this class, not just follow outlines that are provided to you.
Motivation
What is the problem that you are solving or the question that you are
answering?
Usually this has to do with some problem that programmers
experience in their day-to-day routine. In that case, explain
how programmers deal with this today, and the limitations of that approach.
Other styles of project are possible. For example, you might port a tool
to a new environment, in which case you would need to say why this is
valuable and non-trivial. Or, you might evaluate multiple tools, in which
case you would discuss why the answer is not already known, and the limitations
of previous evaluations.
Approach
What is your high-level approach?
It should be clear why this approach addresses the key problem.
State the key difference between your
approach and previous approaches: why might you
succeed whereas others have failed?
State limitations of your approach; this is important for scoping your work
and for understanding its pluses and minuses.
You might give the system architecture,
describing at a very high level the components / modules that will interact
in your system along with existing components you might reuse,
though doing so is not a requirement.
Challenges and Risks
What is the single most serious challenge you see in developing the product
on schedule? How will you minimize or mitigate the risk?
Make the goals of your study more clear from the beginning. Then, when discussing metrics or measurements that you will perform, tie each one to a specific goal or research question. If you cannot do this, then you may have missed a goal or research question, or you may not need to compute that measurement. You will also collect qualitative data, so the metrics don't necessarily cover every goal or research question, but each of them should be covered by some data that you gather.
Your paper should be self-contained. It should explain concepts and algorithms without assuming that the reader is already intimitely familiar with the problem domain and the related work. It should not use terms without defining them. You can assume an undergraduate education in computer science — you don't need to explain the meaning of terms like O(n), for example.
You will present your proposal to the class. All group members must participate in some way in the presentation. You should practice your presentation ahead of time. You will have a time limit of 4 minutes, strictly enforced. Taking less than 4 minutes is perfectly OK. Padding out your presentation to 4 minutes to run down the clock is not OK. Don't waste anyone's time.
Some projects will not go beyond the presentation stage, and others will be staffed and actually implemented.
After viewing all the proposals, you will have a chance to talk with other members of the class, to self-organize into groups, and to rank the proposals that you wish to work on. You will submit, via email:
If you submit a list of project partners, then everyone else whom you list must submit an identical list of sorted project partners, and must submit an identical list of ranked projects. Otherwise, the staff may interpret, or ignore, all of those people's requests (and grade you down for not following instructions).
After receiving your requests, the staff will organize all of the students into final project groups. We will use the following criteria.
Your grade is not based upon whether your project is chosen (by other students or by the course staff) to be implemented. Rather, your grade is based on the quality of your materials and your presentation. We will be looking to see that you have addressed the identified project elements, that you have made reasonable judgments concerning them, and that you have organized and presented your proposal well. Remember that this delivery is the basis for the class to decide which products to develop and deliver this term.
Before you start your proposal, make sure that you figure out what existing products are, their strength and weakness etc. so that you won't repeat previous works. It's also important to read related works to learn more about your specific topic and area so that you notice customers' needs, current difficulties, current accomplishment in other related studies. You can find related work on:
This section gives some tips about your proposal, based on what students have done poorly in previous quarters. Don't repeat these same mistakes! (Not all of them apply to the document you will write.)
It is essential that you clearly indicate what the problem is, and why it matters to potential users of your system. For example, how will the system change the way they they perform some task? Too often, this most important part of the presentation was not clear.
If you are building a system with a GUI, then at least one of your diagrams should be a mockup of your proposed GUI.
You have a limited amount of time and space, so use them well.
Don't make the mistake of diving into too many technical details. You can say a few words about the underlying technology, but your first priority should be to explain why the project is interesting. Only after that is it worthwhile to say that it will be possible (or even fun) to build.
You must discuss alternatives. (When you prepare your presentation, you should spend nearly as much time understanding what already exists as you do coming up with something new.) There is no point re-inventing the wheel. Don't propose a web search engine without knowing that Google exists. No matter how many times we state this, students repeat similar mistakes. If you have trouble finding related work, try here.
You need to explain clearly what differentiates your product from the alternatives. Make sure it is possible to build and evaluate in a quarter — for example, if it needs a large amount of data to provide beneficial results, where will you get the data? Don't assume you will solve natural language processing as one component of your project.
Be concrete, and give examples—whether you are explaining a problem or a solution. For example, don't give generic risks that would be equally applicable to any project.
Make up a short, catchy title for your project and use it as the title of your document and your slides.
See Michael Ernst's advice on giving a technical presentation. Most of it is applicable to your presentation.
Common problems with slides:
The slides should be simple and readable. The last thing you want to do is to distract the audience from the content with extraneous ink on your slides. It's unprofessional, and any intelligent audience member will see it as an attempt to dress up inadequate content.
Don't read from a script. If you need a script, you don't know your material well enough.
Don't sound bored. Do look at the audience: not at the laptop, and definitely not at the slides which puts your back to the audience. You can look at the slides occasionally but shouldn't need to read from them as a script.
Don't put your hands in your pockets. It makes you seem unengaged, and by constraining your body it actually reduces your energy level.
4 slides means 4 slides, including the title slide if any.
Use color effectively. Especially if you have a lot of text (which is a problem already) then it is good to highlight the key points to draw the reader's eye and indicate what really matters about the slide. Too many presentations use only black.