[130 home]
There are two homeworks, a standard software requirements specification (SRS) and a project. These are independent of each other. You do the SRS by yourself; the project you typically do with a group.
First, you will meet with a potential "client" in a 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.
Second, in a later discussion section you will once take the role of being a client for a few of your fellow students, and a few times you will take the role of being a software engineer and will generate a requirements spec for that application. When you are a client, you'll be given one of the following application areas where you will pretend to have a definite need, so that your fellow students can write the requirements for the application that you need.
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 or so we will cover the available projects and what their motivations are. If you have a project of your own that you'd like to do, please propose it to the TAs by the end of the first week. 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 tentative list of project clients includes (more will be added later):
gzip speedup via pigzAfter projects are presented, please indicate your preferences (following instructions given during discussion section) by Wednesday, 2018-04-11, 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. All due dates must be before the last day of instruction (i.e., the last discussion); 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. Weights total to 40% of the final grade.
| weight | due | assignment |
|---|---|---|
| 4% | 2018-04-23 | project timeline, requirements version 1 |
| 1% | 2018-04-27 | requirements version 2 |
| 9% | 2018-05-11 | midterm report and testing |
| 6% | 2018-05-11 | midterm presentation and demos |
| 2018-05-30 | start final report | |
| 14% | 2018-06-06 | final report and testing |
| 6% | 2018-06-08 | final presentation and demos |
Other projects may need different schedules. However, each project must generate a final report, due by the last lecture.
By convention, assignments are due by 23:55 on the specified date on your schedule (i.e., five minutes 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.