[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