First draft due date: September 12
Final due date: September 18
Note: Homework assignments are individual work, even when they relate to the project. You may discuss your assignments with each other, but the work must be yours alone.
Problem #1. Using GanttProject, make a project schedule called hw1.xml of the elaboration phase of the grading system project, assuming you have four team members Amy, Bob, Chris, and Dan.
Note: There are many possible solutions to this problem.
Problem #2. Prepare a progress report that describes your activities for this assignment.
| Date | Activity | Time spent |
|---|---|---|
| 2006-09-06 |
Read Kruchten ch. 7 |
1 hour |
| 2006-09-07 |
Created draft schedule |
2 hours |
| . . . |
||
| TOTAL |
x hours |
Problem #3. Prepare use cases for a part of the grading system.
Here is a general problem description:
Your team will be implementing a system for assisted grading of student homework assignments in a CS1 course.
Here are some sample assignments. hw1 hw2 hw3 hw4 hw5 hw6 hw7 hw8 hw9.
Assisted grading means that the software should aid the professor by carrying out as many of the repetitive tasks as possible, but it should not attempt to replace a competent human grader.
A) Preparation. An assignment consists of one or more problems. Before a student can submit an assignment, the instructor must have provided information about each problem in the assignment. The information includes additional source or JAR files that are required for compilation, the tests that should be carried out for preflight and grading (including test inputs and expected outputs, or perhaps a correct solution whose behavior can be compared against the student solution, or a JUnit test class, or an image file that should match a screen snapshot of the student program—these are details for you to specify) and the scores that are awarded for success. It should also be possible to run a style checker.
B) Submission. A problem requires the student to submit one or more files. You will design a mechanism for file submission. (Paste files into text areas? Upload a separate zip file for each problem? A single zip file per assignment? With what directory structure?)
There will be a preflight check that informs the student whether a submission is valid. (E.g. names of classes, compiler errors, smoke tests,... You will decide which checks you will carry out.) Students are allowed to resubmit (within reasonable limits that you will specify) if their submission fails the check. Failed submissions are logged, and the instructor can review them. You decide whether they resubmit individual problems or the entire assignment.
C) Grading. There may be one or more graders, each of whom grades an entire assignment without knowing what the other did. The instructor reviews the work of the graders and resolves differences in scoring. The differences should be appropriately marked. Both the graders and the instructor are able to modify the files in the student submission and re-run the grading. The original and modified files need to be preserved. There shall be an easy way for graders and instructors to view the submitted files so that a grade for style can be given. Both the graders and the instructor are able to override any automatic score, and to add explanations of their overrides.
One important feature is the ability to do some grading, log off, and return later to the same grading session, seamlessly picking up the work.
Another important aspect is that the grading screen must be maximized for efficiency. A grader will want to see all relevant data corresponding to a particular problem on a single screen. A grader will want to grade all solutions of a particular problem before moving to the next problem in the assignment.
D) Reporting. There will be reports both for the instructor and for students. Instructors will be able to see how a particular student performs relative to the others in the class. They will be able to see how all students did on a particular assignment. There will be a display that shows the performance of graders; e.g. which grader required more overrides. Students will be able to see a report that shows how their assignment was graded: what worked, what error messages were caused, what actions were taken to make their programs compile, what remarks the instructor made (grader remarks are not visible unless the instructor chooses to make them visible). Students will also be able to compare their result against other class members, but no personal information about the others should be revealed. You should design at least one other report type beyond the ones mentioned here.
Your individual homework assignment is to write use cases for the part assigned to you.
A) athens1, berlin2, london3, stockholm1, paris5, rome1, stockholm4, vienna1, vienna5, warsaw2
Use cases:
Note that the first use case is quite long because there are so many grading options
B) athens2, berlin1, berlin3, london5, paris1, rome2, stockholm5, stockholm6, vienna2, warsaw3, warsaw5
Use cases:
Note that the first use case is quite long because so many things can fail during the preflight check.
C) athens3, berlin4, london1, stockholm2, paris 2, rome3, rome5, vienna3, warsaw4
Use cases:
D) athens4, athens5, berlin5, london2, stockholm7, paris3, paris4, rome4, stockholm3, vienna4, warsaw1
Use cases:
Problem #4. Prepare screen mockups (using HTML forms) for each of your use cases.
Your solution will consist of files hw1.xml (Gantt chart), report.html, hw1.html and files for use cases and screen mockups (all in HTML). The file hw1.html contains links to the use cases. Link to the screen mockup files from the use cases. All files are contained in a project directory hw1.
You will check your solution into your individual CVS sandbox. I will check out your work with the following commands:
export CVS_RSH=/usr/bin/ssh export CVSROOT=:ext:username@oslo.cs.sjsu.edu:/home/cvsroot/sandbox/username mkdir -p ~/gradehw1/username cd ~/gradehw1/username cvs checkout hw1
I will then point my browser to ~/gradehw1/username/hw1/report.html and ~/gradehw1/username/hw1/hw1.html. You will want to try this yourself.
You will make at least two checkins. On September 12, you will check in an up-to-date progress report, a Gantt chart that contains at least all tasks for the SRS and at least one use case and their supporting screen mockups. On September 17, you will check in your final submission. You are, of course, encouraged to frequently check in intermediate submissions.