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. Think of it as the CSE equivalent of Shark Tank, except we are nice, we want you to succeed, and we will help you succeed.
You are not limited to the areas described in the topic summaries — the project proposal you present can be anything that would help a software engineer do their job.
This assignment must be completed in groups of 2. (As an exception, one person may complete the assignment in a singleton group, but this requires approval from the course staff.) There will be time in class to find a partner. You can also use the forum to find a partner.
First, you and your partner should create a new group on Canvas. Only one partner needs to submit the assignment.
You will produce two deliverables for this assignment, and submit them both to the Canvas assignment:
Make up a short, catchy title for your project and use it as the title of your document and your slides.
You will submit both deliverables electronically, in PDF. Each deliverable should include at least one figure or diagram (possibly the same, possibly different).
At the end of your document, state many hours you spent on the assignment.
The two deliverables should address similar issues, though they should do so in different ways, since different formats (written vs. oral) 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 and is not appropriate for every pitch; we expect you to think in this class, not just follow outlines that are provided to you.
Motivation
What problem are you solving, or what question are you answering?
Explain how the problem is handled today, and the limitations of that approach. For a question, explain why its answer is of value.
Often the problem is something that programmers experience in their day-to-day routine. Think of concrete examples and see how the solution would work. Are there any limitations to the approach? Who would benefit most from the tool and more specifically, how does it improve software quality, decrease cost, or have some other benefit?
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 project clear from the beginning. Then, when discussing metrics or measurements that you will perform, tie each one to a specific goal or question. If you cannot do this, then maybe you have missed a goal or question, or maybe that measurement is not needed. You will also collect qualitative data, so the metrics don't necessarily cover every goal or question, but each goal or question should be covered by some data that you gather.
Your proposal 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 3 minutes, strictly enforced. Taking less than the time limit is perfectly OK. Padding out your presentation to run down the clock is not OK. Don't waste anyone's time.
Listen attentively to the other presentations. Would you want to work on this project? Would you want to work with this person? When you are presenting, remember that the rest of the students will be thinking about these issues.
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, to an online survey:
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.
Don't reinvent the wheel. Before you start your proposal, discover related work, so that your effort is of scientific or practical value. General web searches are useful. For scientific papers, also see
This section gives some tips about your proposal, based on previous quarters. Don't repeat these same mistakes! (Not all of them necessarily apply to your document.)
It is essential that you clearly indicate the problem, and why it matters to potential users of your system. For example, how will the system change the way 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. (For this assignment, you should spend at least 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.
You need to explain clearly what differentiates your project 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.
See Michael Ernst's advice on giving a technical presentation. Most of it is applicable to your presentation. The below issues are discussed in that document.
Don't use small or hard-to-read fonts or colors.
Don't use background images, or design elements on the slide. 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: don't stare 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.
Respect the slide limit, which includes 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 text.