[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [school-discuss] Gradebook Specification



Hi Doug,

>One of the most important things, I think, is to "internationalize" this from
>the start.  Don't assume US/Canadian norms, but make it flexible enough to
>work for UK, Greek, South African, Singaporean, etc. schools.  I'll give a
>few examples of such stuff in my comments below (I'm no expert in this, so
>take my recommendations as concepts, not good solutions).

Good idea, but we'll need specifics.

>Les Richardson wrote:
>
>> Reflecting upon a basic gradebook spec, I've come up with several tables
>> in a database:
>>
>> 1) Student - student information including:
>> a) Lastname
>> b) Firstname
>> c) Student Number (local or state/provincial)
   d) Password (MD5 encoded)
   
 
   What else will be needed to describe a student? This could be all since
another table could carry student demographics, linked via student number. 

>>
>
>"Lastname" and "Firstname" should be "Familyname" and "Givenname" or
>something similar to cover different name ordering among cultures.
>Demographic fields should also be flexible (not requiring a state/province or
>a postal code, for example, as some countries have neither).

This shouldn't affect the database structure, only the descriptive fields.


>> 2) Tests - a particular assessment device given to students in
>> a particular class/section taught by a particular teacher.
>>
>> a) TestID - unique number
>> b) Subject ID/Description - a particular subject. May match value in
>> another "subject" table or not.
>> c) SectionID - a particular "section" or "group taught by a particular
>> teacher.
>> d) Description of test/assessment device.
>> e) Date of test
>> f) Maximum Raw Score.
>> g) Weighting (for total assessment results.)
>> h) Category A - useful for grouping assessment types.
>> i) Category B
>> j) Category C, etc.

Each category should carry a descriptor (ie. Participation) and a weighting
(ie. 10%)


>> 3) Results - students' results from tests.
>> a) Student Number
>> b) Test Number
>> c) Raw Score
>> d) Text Descriptor of result.

   e) Category - to allow for calculations within weighted group.

(ie. This category is worth 30% of final mark. There are 3 items entered so
far:

Item 1:   30 marks total - raw score  18
Item 2:   25 marks total - raw score  21
Item 3:   15 marks total - raw score  14

Total Possible: 70,  actual 53

This category will then be worth  53/70 x 30 = Marks toward overall mark.
Notice that _within_ a category, the weighting depends on the total number
of marks for that item.

It that correct/appropriate?


>
>We should hear from different systems how student test results are tracked.
>In the US, there are (AFAIK) three standard ways: percentage correct, letter
>grades from A (best) through F (worst), and Grade Point Averages (from 0.0 to
>4.0, 4.0 being perfect).  I'm sure there are other methods in use in the
>world.

The datafields for the student test results should be character based, not
numeric.
Code can then do any required conversions, calcs. Enumerated types (ie.
A-F) could have a numeric equivalent to allow calculations. The gradebook
system normally deals with numbers although input and output could be in
terms of "fuzzy" results. (ie. sort of like a multi-integer roundoff
function...<grin>)

Les Richardson