Semester Project

The following table summarizes the performance of this semester's final project software. Apart from Team ZERO, whose sad story is told below, the Team IDs were generated randomly.

The table is sorted by the program's reliability on part 8 of the test script. That reliability was calculated by subtracting the number of false positives and false negatives and half the number of inaccurate offsets from the number of correctly reported matches, and dividing that result by the number of matches that should have been reported. In the table, negative reliabilities are shown as zero.

Ties were broken by sorting with respect to the software's time efficiency on the stress test (part 10), which is the second most important measure of software quality shown in the table. Programs that took more than 30 minutes to complete the stress test are sorted by their time efficiency on part 8.

Three projects completed the stress test very quickly because they threw an exception. Those projects are listed as failing the stress test.

One team submitted source code (and an executable program) that had been configured to create temporary files in a particular team member's personal directory instead of the /tmp directory. As you might expect, that software performed miserably, failing almost every test we used for grading (because we, like Dan Wear and other users of the software, did not have permission to create files in that student's directory). The program's source code looked fine to the naked eye, however, so I spent some time debugging it. It turns out that correcting just one line of code would have reconfigured that software to use the /tmp directory, and the reconfigured program would have performed the best of all programs submitted instead of being one of the worst. The performance of that corrected program is shown in the line for Team ZERO.

It might be interesting to compare this table to a similar table for the graduate course on software development.

Last updated 12 December 2014.