Right, first off, you are citing the brief and claiming that this is the basis on which people are marked. This is the very mistake I stated in the grandparent post and that you are making again. Stop claiming I am making 'assumptions' when you obviously have no clue as to the facts. The mark scheme is found under the 'Detailed unit content' section and that specifies a lot of things you need to do in addition to simply 'making a product'.
> without further information, you aren't in a position to say that he ignored the spec
So if you read between the lines in the student's statement, where in this did he say he did anything other than write some code? And you're accusing me of making assumptions?
> The article's direct statements trump your assumptions.
So find me the statements which show he actually did all the legwork you are required in the class. You are completely wrong here.
> From the spec. on the site you linked to - it seems Unit 4: Creating Digital Products is the relevant unit
It's not in fact the relevant unit, as there are several exam boards he could have used. That was given as an example (was in fact my coworker's unit). The brief actually matches OCR's ICT course (section 2.4):
Note how there is no requirement as to how to implement it. But also note how there is no requirement for candidates to show their code, even!
The student says:
> I argued the case and managed to scrape a pass by teaching him the basics of Objective-C from scratch and by commenting every single line of code I wrote to explain exactly what it did and how it did it (all 3,400 lines, including standard libraries I used) which ended up being a huge time sink.
This kid didn't read the mark scheme or he would know that you are not asked to comment the code, nor does doing so confer any direct proof that you can do any of the things that spec says you should demonstrate.
You're meant to show designs for the different parts of your programs, you're meant to demonstrate that you wrote code and that it does what you say it does, and you're meant to establish a testing procedure and document the outcome, among other things.
What you do NOT do is comment your code and call it a day. I know because I tried doing precisely that in my own project and was told "we don't want code, we want documentation". When the teacher says he doesn't have a clue how it works, it's because he was given a code dump. Documenting it so that a non-programmer can understand what you are doing is tedious but that is what you're being asked here.
> without further information, you aren't in a position to say that he ignored the spec
So if you read between the lines in the student's statement, where in this did he say he did anything other than write some code? And you're accusing me of making assumptions?
> The article's direct statements trump your assumptions.
So find me the statements which show he actually did all the legwork you are required in the class. You are completely wrong here.
> From the spec. on the site you linked to - it seems Unit 4: Creating Digital Products is the relevant unit
It's not in fact the relevant unit, as there are several exam boards he could have used. That was given as an example (was in fact my coworker's unit). The brief actually matches OCR's ICT course (section 2.4):
http://www.ocr.org.uk/download/kd/ocr_31062_kd_gcse_2010_spe...
Note how there is no requirement as to how to implement it. But also note how there is no requirement for candidates to show their code, even!
The student says:
> I argued the case and managed to scrape a pass by teaching him the basics of Objective-C from scratch and by commenting every single line of code I wrote to explain exactly what it did and how it did it (all 3,400 lines, including standard libraries I used) which ended up being a huge time sink.
This kid didn't read the mark scheme or he would know that you are not asked to comment the code, nor does doing so confer any direct proof that you can do any of the things that spec says you should demonstrate.
You're meant to show designs for the different parts of your programs, you're meant to demonstrate that you wrote code and that it does what you say it does, and you're meant to establish a testing procedure and document the outcome, among other things.
What you do NOT do is comment your code and call it a day. I know because I tried doing precisely that in my own project and was told "we don't want code, we want documentation". When the teacher says he doesn't have a clue how it works, it's because he was given a code dump. Documenting it so that a non-programmer can understand what you are doing is tedious but that is what you're being asked here.