Due: pairs by Tuesday, March 29, 23:00
Due: proposal documents by Thursday, March 31, 23:00
Due: presentations in class on Friday, April 1
Due: project preferences by Friday, April 1, 23:00
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.
This assignment must be completed in groups of 2. Fill out the proposal pairs form with your pairs. Exactly one student per pair should fill out the form. If you do not have partner, fill out the form by yourself, leaving the partner fields blank. The staff will randomly pair all students who do not have a partner by Tuesday at 23:00.
You will produce two deliverables for this assignment:
For anything that you submit in CSE 403, place partners' names and UW and CSE user 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 CSE 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 do 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 — in other words, why might you
succeed whereas others have failed?
State limitations of your approach; this is important for scoping your work
and for understanding its plusses 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?
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 3 minutes, strictly enforced. Taking less than 3 minutes is perfectly OK. Padding out your presentation to 3 minutes to run down the clock is not OK.
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:
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).
Catalyst might not permit you to change your submission, so try not to submit until after you have made a final decision. If you have to change your decision, then tell the staff.
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 works 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 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 works, 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.
3 slides means 3 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 of the presentations used only black.
Sample proposals from previous quarters can be found here: