There are two homeworks, a standard software requirements specification (SRS) and a project. These are independent of each other, and overlap: in fact, the project starts before the SRS. You do the SRS by yourself; the project you typically do with a group.
You will meet with a potential "client" in the third 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 specificiations, please see Donn Le Vie, Jr., Writing software requirements specifications, TECHWR-L (2007-03-07). You should also take a quick look at the class's resources for written reports.
This homework is due one week after the client meeting.
This consists of analyzing, designing, implementing a real-world project with a real-world customer. By the first discussion section 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.
Our current list of projects includes the following, listed in the order that they made their presentations (i.e., no particular order):
After the first discussion secton, please email project preferences to the class TAs (CC: to the instructor) with the Subject: line reading "CS130 preference". The first line of the message body should be your name and Student-ID, and the next six lines should be your preferred projects in descending order of preference (using the keywords picturebook, adventure, wine, sharing, rollcall, and syndiff, respectively). Please append any other information you find useful after those six lines. The deadline for this email is this Monday, 2008-01-14, at 17:00 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. Here is a schedule that may be appropriate for a greenfields project.
| weight | due | assignment |
|---|---|---|
| 5% | 2008-01-28 | requirements |
| 5% | 2008-02-08 | specification |
| 10% | 2008-02-22 | subset implementation |
| 10% | 2008-03-07 | full-featured implementation |
| 10% | 2008-03-14 | demonstrate polished version |
Other projects will no doubt need different schedules. However, each project must generate a final report, due Tuesday 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.