4. Developer Overview

This section contains information for the developers that will turn this specification into an implementation. Any recommendations for implementation are suggestions by the specification team to help the developer understand and complete the implementation more quickly.

4.1 Major Structural Overview

The three primary structural components for development are:

The gradesheet will be the majority of the development effort for this project. The gradesheet is the spreadsheet-like interface that contains all the student and grading information. The implementation will require a medium complexity GUI, computational functionality to compute student grades, and a lot of spreadsheet functionality. A professor may change information in any cell at any time, and all dependent cells must automatically update. This will require a well planned design to operate efficiently.

As a warning from the specification team, the development team must find a way to have columns within columns on the spreadsheet for sub-parts of assignments. This may not be a standard capability of graphical table libraries. Therefore, we suggest that the implementation team solve this problem in advance so it does not cause unexpected delays in delivery time.

Another major module that must be considered by the implementation team is the grade scale functionality. The Grader program has three ways to manipulate the underlying mapping from a numerical score to a letter grade: the manual grade threshold interface, the histogram interface, and the pie chart interface. The manual grade threshold interface will be simple to implement, however the pie chart and histogram may be more difficult because they are non-standard interfaces.

When implementing the histogram, some challenges that will need consideration include how to implement the draggable grade lines that will snap to the nearest score when released. The draggable grade lines must also have stacking capability to allow professors to put two grade thresholds on top of one another. These are not extremely challenging obstacles, however they are not standard GUI patterns and may take more time than predicted. The pie chart has similar implementation challenges with snap-to lines and stacking. All three grade manipulation interfaces change the same underlying information and therefore should have some sort of locking on the information. Because these three interfaces are so intertwined, we suggest grouping these items during the development work breakdown.

It is also suggested that the development team should group the Post Grades to SIS Interface and the Post Grades to Students Interface. Although they serve very different purposes, they have a lot of common functionality. The Post Grades to Students Interface takes all the current information from the professor's gradesheet and posts it on a department server for students to view. The Post Grades to SIS Interface takes all the completed grading information and sends it to the administration for record keeping and student transcripts. The Post Grades to SIS Interface has the additional complexity of an electronic signature. These components are relatively straight forward, but must be implemented carefully because there are very severe legal consequences associated with student identity and grade information.

The information and comments contained in this section are merely suggestions by the specification team. For more detailed and authoritative information please refer to the requirements and specifications contained in this document. Developers are not required to follow the suggestions contained in this section as long as the finished implementation complies with the specification.






Prev: non-functional | Next: [none] | Up: index | Top: index