GCSE Computer Science

Transcription

1 GCSE Computer Science 4512/1 Practical Programming Report on the Examination 4512 Summer 2014 Version: 1.0

2 Further copies of this Report are available from aqa.org.uk Copyright 2014 AQA and its licensors. All rights reserved. AQA retains the copyright on all its publications. However, registered schools/colleges for AQA are permitted to copy material from this booklet for their own internal use, with the following important exception: AQA cannot give permission to schools/colleges to photocopy any material that is acknowledged to a third party even for internal use within the centre.

3 General Comments This is the first series of the GCSE Computer Science specification and the first submission of the controlled assessment tasks for the Practical Programming component 1 of the qualification. Administration Many centres provided wel- organised portfolios, with correctly completed forms and paperwork, thank you. However, some candidate work was disorganised and not in the correct order, securing work with a treasury tag is the AQA recommended way of presenting finished assessments However, there were some problems with electronic submission of work. Centres must ensure that all their electronic media are tested and checked before sending to the moderator. Please do not send executable files or program files as moderators are unable to open or run these programs. If those types of file are the only evidence of the student's program then no marks can be awarded for parts of the marking grid. The student needs to provide one or more of a printed listing, copied code in a word processed document or screenshot evidence of the program code. The best centres to moderate electronically had a single document for each candidate for each scenario, identified clearly with candidate number, name and scenario title. These centres submitted either PDF files or DOC files and included paper copies of the completed marking grids. Only pdf or word versions of correctly labelled files will be moderated. Internal standardisation has a significant effect on candidates awards. To ensure consistency, centres must standardise their marking across different teachers assessing candidates' work. Several centres chose not to add teacher comments on the marking grids. It is very useful to moderators to understand why the teacher has awarded marks, as a clarification can help the moderator to decide whether to agree, or not, with the teacher. Centres are encouraged to use the marking grids as a means of communication with the moderator about why marks have been awarded. All appropriate paperwork needs to be fully completed and signed - including the Centre Declaration Sheet and the Candidate Record Form. There were some assessments without a candidate number and the necessary Candidate Record Form. Failure to comply with these requirements can cause delays in carrying out the moderation process. In electronic submission it is preferred that the marking grids for the candidates are printed and included in the pack to the moderator. Scenarios A very wide range of software solutions were presented for this series which was good to see. Most centres used software appropriate for the scenario tackled. The specification and scenarios do not prescribe a particular programming language for a scenario; however, the mobile and web scenarios do have specific platforms on which the solution must run. Unfortunately a few centres who tackled the mobile scenario used software that was not appropriate, for example VB.NET. The mobile solution must be able to be run natively on a mobile device without the use of a web browser. The program should be executed by the mobile operating system such as android or ios as an app. Unfortunately some students were unable to be awarded some marks because of this. It was common to see AppInventor used to develop a solution for this scenario, and some centres used other SDKs such as Basic4android. Others however tackled the problem using a web based solution and this is not suitable for the mobile scenario. Some candidates used Gamemaker to attempt the traditional scenario and as Gamemaker does not have file handling capabilities this decision limited the ability of the candidates to access the full range of the tasks within the scenario. 3 of 8

4 Marking In some cases it was disturbing to see very high marks awarded for student work that was minimal or non-existent. Centres must ensure that their marking is based on the evidence presented in the portfolios sent to the moderator. It is very difficult, if not impossible, to agree marks awarded by the centre if we cannot see what the student has done and what their understanding is of what they have done. This is not only an assessment of student ability to produce a competent programming solution but also an assessment of their understanding of what they have produced and evidence needs to be shown to award marks, particularly in section 3. Section 1 Design of Solution Row 1 Some students provided a verbatim copy of the scenario and so could not be awarded any marks. Others simply changed the occasional word or phrase and, therefore, marks in those cases were also limited. The specification requires students to analyse the problem, in this case the scenario provided. They should identify and collect information relevant to solve the problem from the context of the scenario. Better students were able to explain the solution based on the scenario given and extrapolate the needs of the user from that scenario. Row 2 Many students made a good attempt at this, often using flowcharts or decision tables. Unfortunately a few students misinterpreted this as a time plan for the development of the solution, planning their work rather than how their solution would be structured and built. The marking requires an overview plan and some students provided so much detail that an overview of how the program as a whole would work was lost. In some cases it was obvious that the overview plan was written after the solution was developed. This means that the planning part of the marking was not met, as plans happen before implementation. This is also true of the pseudo code or equivalent in the next section. Row 3 The better students produced good quality descriptions of the main blocks of coding required to create the solution. The pseudo code (or equivalent) produced must be language independent to be awarded the higher marks in this row. In some cases it was obvious that the pseudo code was written after the solution was coded and the students often included program language specific constructs and syntax. In those cases marks were limited. We do not expect perfect or complete pseudo code as this is the design stage of the development process. The student needs to show they have done some preparation work before getting into the coding. They have been able to design and structure their proposed solution ahead of time, therefore showing skills in logical thinking and analysis. There were many students who provided alternatives to pseudo code, often in the form of detailed flowcharts, descriptions of algorithms, decision tables etc. These were sometimes combined with high level overviews for row 2, and this is perfectly acceptable, however, we do want to see a highlevel plan and then the detail but they do not have to be in distinct sections to get marks for both rows. 4 of 8

5 Section 2 Solution Development In this section marks are awarded for the practical development of the solution. Many students provided code listings in various forms. The presentation aspects of this evidence need to be addressed, however. Where there were block coding solutions such as Scratch or AppInventor most students provided screenshot evidence of the blocks; sometimes these were too small to read or were incomplete. Gamemaker solutions were also sometimes not documented clearly. If a solution is developed in these languages there is usually an interface that is relevant to the coded solution and this needs to be shown as well. Please instruct students to ensure that the evidence is legible. We cannot credit work we cannot see or read. Row 1 Many students provided evidence of the (screen shot) output of the final solution working, and annotated this. However this is not showing that the coding meets the needs of the user, at most it shows the solution working and can be used as evidence of testing. This section relates to the development of the solution so marks are awarded here for an indication of how each part of the program attempts to meet the user needs. Many students gained marks for this row in the annotation of the code itself, if that annotation referred to the requirements of the scenario as related to the user. Row 2 Wide variations of solutions were observed, and were mostly marked accurately by centres. In a few cases, however, higher marks were awarded for solutions that were minimal. It was a cause for concern to see how some centres awarded high marks in this row and section 3 row 3 when the student had not produced any workable code. Row 3 Annotation of the code took a number of forms. Some students added program comments in the code itself, others added annotation to the word-processed listing in the form of callouts or text boxes. Either way is fine. Better students commented the main constructs within blocks of code, others added general comments for each main block. The annotations were also used in some cases to state or describe programming techniques and so gained credit in section 3. 5 of 8

6 Section 3 Programming Techniques Used Evidence for the rows in this section could come from several areas. Some students had a separate section and attempted to describe and discuss the programming techniques used by row theme (working together, efficiency, data structures, and robustness etc.). Others used a detailed annotation of the code in sequence and as part of the documentation of the solution to discuss the relevant aspects required for this section. Whichever method is used it is important to note that marks can only be awarded if the evidence is explicit. Row 1 If a student had produced a well annotated code listing that included a description of the main constructs of the program then they had stated the techniques used and could gain the lower banded marks. However, the better students included a description of the techniques and the best students considered alternatives by discussing what else could have been used. This distinction in the level of detail required is true of most of the rows in this section, in particular rows 2, 4, 5 and 6. Row 2 Some students provided a diagrammatic representation of how blocks of coding worked together and that was often an effective way of describing how different parts of the solution work together. Some students provided a description and discussion section which was also good. Other students did not provide separate evidence for this but there were techniques used in the code itself that showed how parts worked together so the student, although limited to 3 marks, could gain credit for the construction of a program whose parts worked together. Row 3 This row is linked to the section 2 row 2 marks and often reflected the scope of the solution that the student had tackled. In some cases, however, the student had attempted to code tasks so gaining credit in section 2 but their solution did not work as intended and therefore marks were limited in section 3. Row 4 This row assesses a student s understanding and ability to code an efficient solution. The student needs to show they have addressed this issue and made some statement in order to gain any credit here. This was the area where there was the greatest difference between centre marks and moderator marks. The marking grid is clear that for a minimum 1 mark the student needs to make a statement about the choice of programming techniques relating to the efficiency of coding. This does not mean a paragraph header with the word efficiently somewhere in the text; unless what the student has stated actually relates to the concept it is not creditable. Better students considered alternatives to code constructs and these gained the highest marks. If the solution is not efficiently coded then marks were often limited to two unless the student had explained why it had not been done. If the code is reasonably efficient then higher marks are awarded for the demonstration by the candidate of their understanding of what constitutes an efficient solution. Row 5 This row is looking for a student to show they understand the data used and processed in their solution. In some scenarios and programming languages this was inherently limited. However students were still able to gain maximum marks by showing they understood what they had been able to do. As with row 4 the student needs to show their understanding. The use of data types and structures in their code is not in itself evidence that they understand what they have done, so the marks are limited unless they explain what had been coded and why it had been done in this way. 6 of 8

7 Row 6 Many students included techniques within their code to make their solution robust and, if they had commented on this either in the code listing or a separate section, they could be credited up to 3 marks. The better students provided a more detailed description and discussed alternatives. It should be noted that we are looking for techniques that the student has used. If the student has not implemented some checking, for example file handling errors or detailed data validation, then they can still get top marks for discussing the robustness of the code they have produced. They may, however, be limited in the testing section, see below. Section 4 Testing and Evaluation Row 1 Many students produced tabular test plans with expected results and test data, which is suitable for row 1, although variations on this were also acceptable. The scope of the testing was sometimes limited so restricting marks. A full or nearly full test plan should contain most expected and possible variations in the use of the software. If the solution had not been coded completely or only a few techniques were used to ensure a robust solution then often the student could not demonstrate a full test plan as they had not considered what could go wrong based on the user needs. This row asks for expected tests and this must relate back to the scenario and what the user would expect to work. Row 2 If the student has not produced a test plan then no marks can be awarded in this row, as the marks are for the evidence that the planned tests have been followed. However, if the test plan was limited in the first place but students had followed the plan then they could access the higher marks in this row, as we do not want to penalise students twice. Some students provided screen shots of their working solution but, unless this related to a test plan including what part of the solution they were testing, then it could not be awarded marks. For two marks the record of the results needed to show whether the test was successful or not, and many students did this, although sometimes limited to a simple yes or no in an actual results column of the test plan table. The better students reflected on the results of the testing and, with screen shots of outputs where applicable, this showed the extent to which the testing was successful. In some cases the students had tested the solution as they developed it and, therefore, the testing revealed a fully working solution with no need for remedial action. In these cases the student is able to gain full marks. Where remedial action was required most students did well in documenting how they carried this out. Row 3 Some students simply repeated the scenario and gave statements on whether their solution had completed the task or not. This limited marks to 1 in this row. For higher marks the students needed to describe how well the solution met the needs of the user. Some did this by showing output of the program but this is not mandatory. For 3 marks a discussion was needed and those students who looked at alternatives and ways of improving the solution often did well in this row. 7 of 8

8 Mark Ranges and Award of Grades Grade boundaries and cumulative percentage grades are available on the Results Statistics page of the AQA Website. Converting Marks into UMS marks Convert raw marks into Uniform Mark Scale (UMS) marks by using the link below. UMS conversion calculator 8 of 8