I read something that Dave Mulkey wrote in this forum in 2009 on the subject of ADTs as a mastery factor:
As I said above, my students never try to get 4 marks, and usually not 3. They just implement the most normal features with normal error checking and that’s sufficient for 2 marks. If they really need 4 marks (say there are no files in the application), it’s easier to implement 2 different ADTs and get 2 marks for each.
Huh?! Can you do that?! It would be great news if so, but I think it needs to be made much clearer in the guide.
That is certainly a good question. I’d agree this is not thoroughly explained in the Guide.
The May 2006 Subect Report says:
“Candidates may gain some credit for all ADTs which have been properly documented, implemented and demonstrated to work via hard copy. Four such ADTs which all work only partially may gain the full 4 marks (although it does seem a hard way to go about it).”
I recommend reading the Subject Reports – they contain lots of clarifications. In case you have a real life and don’t want to read all of them, I recommend May 2006 and May 2009 as being particularly helpful. May 2009 has a nice chart about Mastery Factors, which is short, clear and useful.
My students don’t create 2 ADT’s very often, but I have given “partial marks” to some of my students for multiple ADT’s, as well as giving them as a moderator. I’ve never heard any complaints about this. Still, what I’m saying is not “official”. If you want an official answer, you can have your IB Coordinator send an official query to the IBO and you will receive an official and binding answer from the office.
Awarding Mastery marks is a subjective issue, with only broad guidelines to help standardize things. The best thing you can do for your students is to clearly explain your thinking, on paper, and include this with the samples that go to the moderator. It’s a lot easier for a moderator to support your marks if they understand why they were awarded, rather than trying to guess what the teacher was thinking. It’s not necessary to explain ALL the marks – e.g at SL if there are numerous IF..ELSE.. constructs throughout the program, a simple list of page numbers/line numbers of a few of them is sufficient. But the ADT marks are quite variable across schools, so a brief explanation from the teacher is very helpful. Also, the students are expected to “document” (explain or discuss or justify) their Mastery aspects. In my experience, the students don’t tend to write very clear (or even correct) explanations, so the teacher’s comments are a big help. If you read those Subject Reports, you’ll see the word “justify” used repeatedly. I think that sounds a bit like arguing a case in a court of law. I prefer the word “explain”. But the Subject Reports are written by the Senior Moderator and/or Chief Examiner (as far as I know), so I would take those suggestions seriously.
From the May 2006 Subject Report:
“Perhaps the biggest issue with mastery aspects is the frequent lack of documentation or inaccuracies in documentation. These cover several aspects such as administrative errors, lack of hard copy output and lack of discussion of the need of the solution for certain mastery aspects.”
The key point there is “the need of the solution for certain mastery aspects”. In this case, I think the statement in the 2010 Guide (p 65) is actually clearer:
” “Non-trivial” means that the programmer must demonstrate that the program benefits from the use of the [mastery] aspect.
Where one aspect includes others, all are credited (always provided that the use is non-trivial, well documented and appropriate).”
I like the idea “benefits from”. Most importantly, the program must actually USE (execute) the code that was written. I’ve seen a number of dossiers where a perfectly functionaly Linked-List has been coded, but is never actually executed. Even more commonly, methods or ADT’s are coded and then executed once, but for no particular reason. Hence the application did not actually “benefit” from using that code.
The worst error (sorry, I’m getting carried away but I must say this) that I’ve seen repeatedly is incorrect use of recursion. Students know they can get a mastery mark for using recursion, so they code a “recursive” method by having it call itself instead of using a loop. Unfortunately, in several cases the recursion was coded incorrectly and never terminated, and the students turned in dossiers with no sample output because the program locked up in an infinite loop. Clearly, those programs did not “benefit” from the use of recursion.
Perhaps that was “too much information”. Hope it helps anyway.