There are two homeworks, a standard software requirements specification (SRS) and a project. These are independent of each other, and overlap. You do the SRS by yourself; the project you typically do with a group.
You will meet with a potential "client" in the second-week discussion section and generate a requirements specification for a software application, the details which will be discussed later. Your job will be to specify the requirements for the application.
For more information on software requirements specifications, please see Donn Le Vie, Jr., Writing software requirements specifications, TechWhirl (2010-08-29). You should also take a quick look at the class's resources for written reports.
This consists of analyzing, designing, implementing a real-world project with a real-world customer. All projects are open source, the idea being that if you're sufficiently successful you can publish papers on your project, put it on your resume, and so forth. Projects are done in groups of up to approximately five students. In the first week we will cover the available projects and what their motivations are. Students will then be asked to list the projects in order of preference, and we will attempt to assign students to project groups in a reasonable manner.
Here is our tentative list of projects. Material in this section is still being prepared so you will need to check back later:
After the first discussion section, please email project preferences to the class TAs with the Subject: line reading "CS130 preference". The first line of the message body should be your name and Student-ID, and the next few lines should be your preferred projects in descending order of preference). Please append any other information you find useful after those lines. The deadlpine for this email is Monday, 2012-04-09, at noon local time. We will assign project teams shortly thereafter.
Your team's first task will be to work with the client to come up with a schedule for this project, along with deliverables, and how much of the course's grade to assign to these deliverables. The weights should total to 40%. All due dates must be before the last day of class; the last two due dates (final report and demo) must be at least by the due dates given in the syllabus. Here is a schedule that may be appropriate for a greenfields project.
| weight | due | assignment |
|---|---|---|
| 5% | 2012-04-16 | requirements |
| 5% | 2012-04-23 | specification |
| 10% | 2012-05-11 | subset implementation |
| 10% | 2012-05-28 | full-featured implementation |
| 10% | 2012-06-06 | final report |
| 10% | 2012-06-08 | demo and discuss polished version |
Other projects will no doubt need different schedules. However, each project must generate a final report, due Wednesday the last week of class.
By convention, assignments are due by 23:59:59 on the specified date on your schedule (i.e., one second before midnight at the end of the day). Please see the grading policy for how assignments are treated when late.
Each project should use the following general rules:
Each student is expected to contribute significantly to the homework. You may share ideas and discuss general principles with others in the class, and obviously you may share work with other project members. With the advance permission of the instructor, you may even share work with members of other projects. However, all the code that you submit as your own must be your own work. Please see Grading for more details. Consult the TA or the instructor if you have any questions about this policy.
Your programs must behave robustly. Among other things, this means they must avoid arbitrary limits on the length or number of any data structure, including symbols, strings, and line length. It is OK to impose a non-arbitrary limit, e.g., because your computer runs out of memory or because of the limited range of the Java int type, but it is not OK to impose an arbitrary limit, e.g., a limit of at most 255 characters in a symbol.
When working on a project, please stick to coding styles that the project already uses rather than inventing your own style, as this saves work for everybody involved. If it is a greenfields project please use a common coding style.