CSE 403: Software Engineering • Project Proposals

Project proposals will proceed as follows: (1) brief project proposals will be done by groups of three or more (form your own groups, using the general discussion board on GoPost, if needed); (2) project descriptions and slides will be submitted by 9:30AM on Friday 3/30; (3) presentations will be made that same day during lecture; (4) preferences for projects and teams will be submitted on Catalyst by 11:00PM that day; and (5) projects and groups will be announced that weekend.

Your project proposals can come from two sources: (1) a set of ideas generated through a series of meetings with the Jackson School KNOW team and me over the past months; or (2) any project you think is interesting and valuable. Any project from either source has to meet the following constraints:

• The project should have some connection to the real world. This rules out many game proposals (but there are counterexamples, like those in the style of FoldIt). The best projects will satisfy someone's need for computation — maybe even your own. Projects arising from the KNOW source surely meet this constraint.
• The project must be able to be installed and run on CSE computers such as the undergraduate lab, and must be installable and testable by the course staff. Please let us know of any new software that you think you might need installed, and we'll try to arrange it.
• This must be a new project for this class; clones or minor improvements to past projects are not allowed. Your product should either cover new territory or have compelling feature(s) that would make your customer select it over related products. Projects arising from the KNOW source surely meet this constraint.
• You may not receive monetary compensation or credit in another course for working on this project (no double-dipping). You are allowed to create something that you think could generate revenue for you in the future, but not to do a project for a particular paying boss/client/organization.
• The project should be of suitable size and scope for to be completed (including design, testing, and documentation) in one quarter by a team of 4-6 student engineers; not much more or less.

Benefits of the KNOW ideas as a basis for defining proposals include having a real (on-campus, willing to meet) customer, having direct potential for getting your software used, and learning about a domain of importance. These are not yet project proposals; they will need to be fleshed out to become proposals. But I would love to see some proposals come out of this effort. Hint, hint!

Sara Curran will make a brief presentation in lecture on Wednesday 3/28; Jessica Beyer will be available during the entire quarter, including the first week, in the Atrium on Wednesday from 2:00-3:00PM and Thursday 11:30AM-12:30PM to help any groups who are interested in proposing a KNOW-oriented project. (We'll introduce Jessica at lecture on Wednesday, and she promises to "wear a bright color so I'm easy to spot in the wild.")

Deliverables

Your proposal will consist of (1) a one or two page document, and (2) a one to three slide presentation (including the title slide, if any). They must both be submitted by 9:30AM on Friday 3/30 (see below for details).

Both deliverables address similar issues, albeit in different ways: project vision, high-level software architecture, and risks. You may consider including, among other points, the following:

• 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. What are the competitors and what is novel in your approach?
• Make it clear that the system can be built, making good use of the available resources and technology. Describe at a very high level the system's arrchitecture, identifying the components/modules that will interact. What is interesting about this project from a technical point of view? Optionally, what languages/toolkits do you propose to use for the development?
• What is the single most serious challenge you see in developing the product on schedule? How will you minimize or mitigate the risk?

These are preliminary and not binding. They will be revised as part of the first milestone, the project's software requirements specification (SRS).

Submit the proposal and the presentation in PDF as described in the Catalyst Dropbox by 9:30AM on Friday 3/30; the dropbox includes specific instructions about naming files, who on the team should submit what, etc. Each proposal will be presented to the class on Friday 3/30. The student or students who will make the presentation should practice ahead of time. You will have a time limit of three minutes, strictly enforced. We'll have all the presentations on a single laptop, to ease transitions between presentations.

Ranking proposals and forming teams

Some projects will not go beyond the presentation stage, while others will be staffed and implemented. After viewing all the presentations and proposals, you will have a chance to talk with other members of the class, and to rank the proposals that you wish to work on. We will have each of you submit:

• A ranked list of the five projects you are most interested in working on. You don't have to include the project you proposed; you may prefer others!
• A list of up to five other students in the class whom you would like to work with on a project.

These are separate preferences; of course, it's more likely to get some or all of your preferred team members if you prefer the same projects! In any case, we will within about 24 hours of getting the preferences, assign teams and projects using these criteria:

• We will try to give you your choice of projects, based on your project ranking. But, just as in the real world, you don't always get your first choice.
• If a project is selected to go forward, then the people who proposed that project have priority for it (assuming that they ranked it highly, of course).
• We may reject, or adjust, projects that we decide are poorly scoped for the course, even if they are preferred by many students. Our objective is to avoid projects that are too easy or too hard, that have an unreasonable chance of failure, that require unavailable resources, etc.
• All things being equals, we will try to balance the types of projects selected.

Here is a table that contains the projects proposed during today's (2012.03.30) lecture, links to slides and proposals.