GCSE Computer Science

Transcription

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

2 Further copies of this Report are available from aqa.org.uk Copyright 2015 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 second series of the GCSE in Computer Science and second submission of controlled assessment tasks for the Practical Programming component 1. The entry was significantly larger this year, with many centres new to the component. A number of issues have arisen in this submission that needs to be addressed by centres. These will be described first before going into the usual detail of the series. The use of teacher standardisation projects These projects are issued to support teacher marking for a particular scenario, and to demonstrate the required standard, in a specific series. They should not be made available to students, as they could be misinterpreted. For example, a project was issued for teacher standardising last year, gaming student 1, Marty. Some students paraphrased Marty's work, particularly in the sections relating to efficiency and robustness. Also, many students included the mislabelled table found in Marty's project. Marty had labelled the table as "Data Structures" when it was in fact a description of programming techniques and credited as such in the Marty marking grid. Marty was actual student work and contained errors and weaknesses that were taken into account when it was marked, and were discussed at standardisation meetings. It would be expected that a teacher could identify these variations in standardising work and take them into account when assessing their own students work. However, students do not have the same level of knowledge, which is why these projects should not be made available to them. Extra functionality Some students included a login function in the web solution, which was a key feature of the 2014 web scenario. This year there was no such requirement yet significant numbers of students attempted it. This extra functionality garnered no marks for 2015 as it was not part of the set task. Scenario tasks should not be changed or added to as the extra work is not awarded marks and is likely to distract students from the main focus of the task. There were a few centres where students embellished the tasks, for example by adding functionality to provide help to the player of the game or expanding on the web site or adding extra rules to the gaming scenario. None of this can be credited in the marking of the student work, and may detract from the time and effort spent by the student on the other parts of the solution that can be awarded marks. Programming language choices Centres must be careful with the choices they make for programming languages and development environments. This decision may limit the ability of students to access the full range of marks within the scenarios as they may not be able to meet all user needs. The mobile and web scenarios require solutions to run on very specific platforms and the choice of language can mean that the user needs described in the scenario are not met, affecting marks across all the sections. For example, the mobile scenario needed to be run on a mobile device or emulator and executed by a mobile operating system such as Android or ios. It also required data to be stored and accessed remotely; some solutions using a console based language simply saved data in variables within the code, therefore failing to meet some of these criteria. There are SDKs that can convert Python, VB or other code to enable it to run on a mobile device. Where this approach is used the student should describe it as a necessary part of the solution development in order to satisfy user needs. 3of 7

4 The web scenario requires code to be executed in a web browser. The use of HTML and CSS to format the look and interactivity of the website is not credited; only the programming code, such as JavaScript, PHP or ASP, used to implement the functionality of the site can be awarded marks. The traditional scenario had tasks that required the solution to read text files, therefore a language that does not allow these tasks to be completed, such as Scratch, would need to be avoided if students were aiming for the higher marks. One of the advantages of having four scenarios is the fact that it allows centres that may have technical issues within their centre to select those scenarios that are suitable for their situation and expertise. Similarities in student work It was noted that students in some centres developed solutions containing parts that were identical across the cohort. This could indicate potential collusion between students or the use of third party written code. Any externally sourced code must be acknowledged by the candidate and teacher and ignored for the purposes of marking the work. It is acknowledged that sometimes there may be a limited choice of ways to code a process, for example connecting to a database in PHP or reading a text file in Python. It is expected, however, that students would show their own variations within the programs, such as the structuring of the program, names for functions and variable naming, to demonstrate independent work. The student and centre must reference the source of the third party work, including snippets provided by the teacher, and this must be taken into account when marking the work across all sections of the report including section 3. This is controlled assessment and should take place under AQA/Ofqual issued rules. The students should be able to use the scenario booklets to develop independent solutions to the problem. In some cases there was evidence of the use of detailed writing frames, where students had been directed on what to write for each section. This is also against Ofqual rules and centres will be referred to the Irregularities Department if it is suspected that writing frames have been used. Portfolios Students must not include any executable code in electronic submissions. Moderators are instructed not to access executable files or files that are not on the supported file type list. If the only evidence of coding submitted is in one of these file types then the awarded marks will be very limited. The guidelines for electronic submission of GCSE Computer Science controlled assessment unit 4512/1 document available on e-aqa clearly states: Work should be submitted in Microsoft Word, Open Office or Acrobat pdf formats only. This will allow for ease of review by the moderator, irrespective of the software they have. If evidence has been produced in video format, this must be saved in a standard video format and in a clearly labelled folder along with the rest of the student s submission. Under no circumstances should executable files be submitted. There were some issues around the presentation of student work. Please ensure all students organise their work in a logical way, preferably following the section by section structure given in the specification and marking grid. For electronic submission it is preferred that all sections are contained in one document that comprises all the sections of their portfolio (ie Design of solution etc) or if this is not practical a series of documents covering all these areas. If a student produces a series of documents, then each document must be clearly labelled with the student s details. 4of 7

5 Students must also ensure that each page has their name, centre and candidate number in the header or footer. It is also very useful for page numbers to be included and referenced by the teacher when marking the work. Please ensure that screenshots are big enough so that the content of the screenshots can be read easily. A very common problem was the inability to see evidence of the solution due to poorly cropped and sized screenshot evidence. In the electronic submission it is also very inconvenient to be zooming in and out of the document in order to see evidence and even then screenshots were sometimes too blurred to read. Section 1 Design of solution Row 1 requires the student to show their understanding of the user s needs. Sometimes all the student did was copy the scenario booklet, just changing a few words. This can only be awarded limited marks and in some cases zero. Better students showed they had analysed the problem and demonstrated their understanding by clearly describing user needs in their own words. Row 2 requires a high level overview plan. Some students interpreted this as meaning a time plan or a design of the interface. These could not be credited. Many students used diagrams to show the program structure at a high level and demonstrated the required understanding of how to plan a program. Some students appeared to develop this after the program was written, so limiting marks. Row 3 requires a more detailed description of the main blocks of the program. This was sometimes done by using detailed diagrams, structured English and/or algorithm descriptions. It is important to understand that pseudocode is a simple description of the logic of a process and should be written in a way that is programming language independent. Many students attempted to provide pseudocode for this row but the quality varied. Some students clearly did not understand what this row was assessing and provided pseudocode that had been copied from their completed solution often including language specific constructs. Design should always be done before the program is written and, therefore, this type of pseudocode could not be awarded marks. Some students successfully used process flowcharts to describe their program blocks. Section 2 Solution development Row 1 requires a student to map their solution to the needs of the user. Some students provided simple screenshots of the output of the program. Unless this is accompanied by a description of the code that produced the output this could not gain credit in row 1. Better students provided a breakdown of the code with an explanation of how user needs were met. This row could sometimes be credited if the annotation of the code in the code listing made detailed reference to user needs, as well as an explanation of the technical aspects of the coding credited in row 3. Row 2 assesses the range of tasks attempted by the student, and was on the whole marked well, reflecting the tasks that the student had covered. Row 3 requires a complete program listing with annotation. Some solutions were documented using screenshots; others copied the actual code into the document. Whatever method is used students must ensure that they can demonstrate that the complete code is shown, and that it is clear enough for the moderator to read. 5of 7

6 Section 3 Programming techniques used This section asks students to demonstrate the level of understanding of the programming techniques used. For example some students made statements that simply talked about using functions but not why they were useful where they were used. Another example was where the student talked about loops but not about how the loops were controlled or why a particular type of loop was used. These statements were sometimes made within the annotation, or as a separate section; either method is acceptable. It should be made clear however that these are statements not descriptions or discussions; therefore marks may be limited to three in some rows. Row 1, If students just say, I used a while loop here then that is a simple statement. If they then say It was used to do so and so then that is a description. Showing a very good understanding would be explaining how the technique achieves what it was selected to do. For example, I used a while loop to keep asking the user to input their name and check whether the input was blank. If it was, then the loop repeated the request. This kept happening until the input was not blank. This shows a very good understanding of the technique. For the highest mark a further discussion of why the while loop was selected rather than a for loop, for example, would have been needed. Row 2 assesses the structure of the solution. The student must write about how different parts of the solution work together to achieve more than three marks. For example, when this variable is set to 1 a broadcast is sent which activates this sprite and this background is changed. Many students did not explicitly describe how different parts of the solution worked together, though their program code showed how this happened. Row 3 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 assesses student understanding of what an efficiently coded solution looks like. One definition of an efficiently coded solution can mean that the code written is efficient in the use of system resources, such as memory and processor time. At GCSE level the understanding for this aspect is at a basic level, for example, using loops that stop when a condition is met rather than running through every iteration. The appropriate use of data types suitable to the function of the variable also can be used to demonstrate efficiency. Efficient code can also relate to the maintainability of the code, the use of appropriate variable names, and the use of functions to save time when updating a program, for example. Many students, however, do not show an understanding of these basic principles, and make generic statements such as easy to use, saves time and fast. These types of statements do not gain credit. Although the student is not expected specifically to use the word efficiently, it is expected that they will talk about why they chose particular techniques or programming structures to improve their programs. They could comment on particular selection, or iteration techniques, or how the program is more maintainable if they use good comments, or how less memory is used if appropriate variable types are used. Efficiency can also include the use of functions, procedures or loops to reduce the number of program steps needed to solve a problem; the code inside a procedure is written once but can be used many times. 6of 7

7 Row 5 requires students to show an understanding of the data used within their program. 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. Row 6 assesses student understanding of a robust solution. The row states clearly that the assessment is based on the techniques used within the code, so extensive testing of the solution is not relevant and cannot be credited for this row. A robust solution is one that handles expected and unexpected errors in the execution of the program. These can be errors in user input such as validation but can also mean that the solution handles all logical paths within the program so that the program provides an expected termination or alternative rather than an abrupt cessation. The student must be able to relate this concept to their solution, describing how their solution avoids these types of problems to be awarded marks for describing the techniques used. Section 4 Testing and Evaluation Row 1 assesses the test plan. For more than one mark the student needs to include test data and expected results. 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 assessed evidence of the results of the testing. If the student had 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. 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. For Row 3, many students provided a personal evaluation of how easy or difficult they found the tasks. These could not be given credit. Some students simply repeated the scenario and gave statements on whether their solution had completed the task or not. This limited marks to one in this row. For higher marks the students needed to describe how well the solution met the needs of the user. 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 7of 7