Due:
proposal pairs at
12:00 on September 29, 2016
via proposal pairs form
Due:
proposal documents at
23:00 on September 30, 2016
via course dropbox
Due:
in-class presentation at
10:30-11:20 on October 3, 2016
in SAV 264
Due:
on
Due:
project preferences at
12:00 on October 4, 2016
via project preferences form
The goal of this assignment is to develop great product ideas, thinking primarily from the customer’s view but also considering feasibility; and then to present those ideas for others to think about.
Your job is to pitch your idea, together with your partner, in hopes of getting your project approved and attracting other team members to your project.
You are allowed to propose whatever project you think is interesting and valuable, subject to the following constraints:
Sample proposals from previous quarters can be found here.
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. You must be logged into your CSE Google account to access the form. If you do not have a 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. The list of pair assignments will be announced on the course webpage.
You will produce two deliverables for this assignment:
For anything that you submit in CSE 403, place partners’ names and CSE usernames 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
title_doc.pdf, and
title_slides.pdf, where title is the title
of your project. Exactly one member of the team should 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 software architecture, 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.
Vision. What is your product, on a high level? Whom is it for? What problem does its solve? What alternatives are available? Why is this project compelling and worth developing? Describe the top-level objectives, differentiators, target customers, and scope of your product. Do not omit the competitive analysis, and indicate what is novel about your product.
Software Architecture. Make it clear that the system can be built, making excellent use of the available resources and technology. What is the product architecture? Describe at a very high level the components / modules that will interact in your system. How are you going to implement the functionality? What is interesting about this project from a technical point of view? Optionally, what languages/toolkits do you propose to use for the development?
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 2 minutes, strictly enforced.
Some projects will not go beyond the presentation stage, and others will be staffed and implemented.
After viewing all the proposals, you will have a chance to talk with other members of the class, to self-organize into teams, and to rank the proposals that you wish to work on. Exactly one member of each (partially formed) team will fill out a project preferences form containing:
If you submit a list of project partners (other than yourself), then no one else from this list may fill out the preferenes form. Otherwise, the staff may ignore your team’s preferences and grade you down for not following instructions. You must be logged into your CSE Google account to access the form.
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 on 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.
This section gives some tips about your proposal, based on what students have done poorly in previous quarters. Don’t repeat these same mistakes!
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?
Since your proposal should focus on the problem, at least one of your diagrams should be a mockup of your proposed UI.
Don’t dive into too many technical details. You can say a few words about the underlying technology, but your first priority should be to convince the staff and the class that the project is interesting. Only after that is it worthwhile to say that the project 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. Don’t propose a web search engine without knowing that Google exists.
To be funded you will need to explain clearly what differentiates your product from the alternatives. As a more minor point, the project should pose interesting design (or other) challenges from a software engineering point of view.
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.
Provide competitive analysis. Don’t belabor features that are standard in existing packages. Indicate what is novel about your proposed features.
One of the most serious risks for many projects is where to obtain the data. Some projects would only be successful with the network effects of a large customer base, and would not be compelling otherwise. In other cases, data may not be available, or is available in a wide variety of different formats. You should not assume that you’re going to solve the natural language processing problem as some part of your project, and you are likely to find that screen-scraping from multiple websites is more difficult than you imagined. You need to clearly indicate how you’re going to collect the data.
Make up a short, catchy title for your project and use it as the title of your document and your slides.
Your slides should be simple and readable. Make sure your fonts are large enough; there is sufficient contrast between the text and background color; and the slides are free of distracting design elements (such as stock background images).
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.
3 slides means 3 slides, including the title slide if any.
Use color effectively. Highlight the key points to draw the reader’s eye and indicate what really matters about the slide.