AQA Level 3 Technical Level IT: PROGRAMMING F/507/6465 Unit 2 Computer Programming Mark scheme

Level 3 Technical Level IT: PROGRAMMING F/507/6465 Unit 2 Computer Programming Mark scheme June 2019 Version: 1.0 Final *196AF/MS* Mark schemes are prepared by the Lead Assessment Writer and considered, together with the relevant questions, by a panel of subject teachers. This mark scheme includes any amendments made at the standardisation events which all associates participate in and is the scheme which was used by them in this examination. The standardisation process ensures that the mark scheme covers the students’ responses to questions and that every associate understands and applies it in the same correct way. As preparation for standardisation each associate analyses a number of students’ scripts. Alternative answers not already covered by the mark scheme are discussed and legislated for. If, after the standardisation process, associates encounter unusual answers which have not been raised they are required to refer these to the Lead Examiner. It must be stressed that a mark scheme is a working document, in many cases further developed and expanded on the basis of students’ reactions to a particular paper. Assumptions about future mark schemes on the basis of one year’s document should be avoided; whilst the guiding principles of assessment remain constant, details will change, depending on the content of a particular examination paper. Further copies of this mark scheme are available from Copyright information For confidentiality purposes acknowledgements of third-party copyright material are published in a separate booklet which is available for free download from after the live examination series. Copyright © 2019 AQA and its licensors. All rights reserved. Level of response marking instructions Level of response mark schemes are broken down into levels, each of which has a descriptor. The descriptor for the level shows the average performance for the level. There are marks in each level. Before you apply the mark scheme to a student’s answer read through the answer and annotate it (as instructed) to show the qualities that are being looked for. You can then apply the mark scheme. Step 1 Determine a level Start at the lowest level of the mark scheme and use it as a ladder to see whether the answer meets the descriptor for that level. The descriptor for the level indicates the different qualities that might be seen in the student’s answer for that level. If it meets the lowest level then go to the next one and decide if it meets this level, and so on, until you have a match between the level descriptor and the answer. With practice and familiarity you will find that for better answers you will be able to quickly skip through the lower levels of the mark scheme. When assigning a level you should look at the overall quality of the answer and not look to pick holes in small and specific parts of the answer where the student has not performed quite as well as the rest. If the answer covers different aspects of different levels of the mark scheme you should use a best fit approach for defining the level and then use the variability of the response to help decide the mark within the level, ie if the response is predominantly level 3 with a small amount of level 4 material it would be placed in level 3 but be awarded a mark near the top of the level because of the level 4 content. Step 2 Determine a mark Once you have assigned a level you need to decide on the mark. The descriptors on how to allocate marks can help with this. The exemplar materials used during standardisation will help. There will be an answer in the standardising materials which will correspond with each level of the mark scheme. This answer will have been awarded a mark by the Lead Examiner. You can compare the student’s answer with the example to determine if it is the same standard, better or worse than the example. You can then use this to allocate a mark for the answer based on the Lead Examiner’s mark on the example. You may well need to read back through the answer as you apply the mark scheme to clarify points and assure yourself that the level and the mark are appropriate. Indicative content in the mark scheme is provided as a guide for examiners. It is not intended to be exhaustive and you must credit other valid points. Students do not have to cover all of the points mentioned in the Indicative content to reach the highest level of the mark scheme. An answer which contains nothing of relevance to the question must be awarded no marks. The following annotation is used in the mark scheme: ; - means a single mark // - means alternative response / - means an alternative word or sub-phrase A. - means acceptable creditworthy answer R. - means reject answer as not creditworthy NE. - means not enough I. - means ignore DPT. - in some questions a specific error made by a candidate, if repeated, could result in the candidate failing to gain more than one mark. The DPT label indicates that this mistake should only result in a candidate failing to gain one mark on the first occasion that the error is made. Provided that the answer remains understandable, subsequent marks should be awarded as if the error was not being repeated. Question Guidance Mark 01 [A] Mark is for AO2 Decision; R. more than one box ticked 1 02 [C] Mark is for AO3 A pointer references a location in memory.; R. more than one box ticked 1 03 [B] Mark is for AO4 comparable in appearance to existing software.; R. more than one box ticked 1 04 [A] Mark is for AO4 aim of reducing duplication of information in a program.; R. more than one box ticked 1 05 [B] Mark is for AO1 enables a website owner to hide source code from the end user.; R. more than one box ticked 1 Question Guidance Mark 06 3 marks for AO1 Maximum 3 marks overall. Example answer: Instead of representing the machine language as binary; the instructions / registers are given names / meaning; assembly language can also be called symbolic machine code; Maximum of 2 from: • machine code is (a stream of) raw data / binary code / 1s and 0s; • that represent instructions / operations / data; • which can be processed directly (by the CPU) / without conversion // which is closest to the machine architecture // which is a lower level language (than assembly language); Maximum of 2 from: • Assembly language uses human readable mnemonics / meta-statements / directives / pseudo instructions // examples of mnemonics; • which represent each (low-level) machine instruction / opcode; • assembly language is one step-removed from/an abstraction above machine code // correct hierarchy, eg closer to human language (than machine code); • Assembly language requires an assembler / conversion / translated / must be assembled; • and is specific to a particular architecture // has little or no abstraction from a computer's instruction set // maps closely to processor instructions; A. Different wording with similar meaning A. Any other creditable answer 3 Question Guidance Mark 07 4 marks for AO3 1 mark for each correct point or expansion point up to a maximum of 4 marks. Example answer A function which calls itself; until a condition is met; such as a function to calculate the factorial of a given number; that function would return the result of (input value of the function – 1)*(return value of the same function called again) // code which shows this; only when the input value is 1 would the function return directly with a value of 1 // code which shows this; Examples include: • a function which calls itself; until a condition(s) is/are met; • it has one or more base cases/conditions; the base case must be reached before the stack size limit exceeds; • in a base case, the result is computed immediately (given the inputs to the function call); • a recursive step computes the result with the help of one or more recursive calls to this same function; but with the inputs reduced in size or complexity / decomposition; moving closer to a base case; • a recursive step decomposes a larger instance of the problem into one or more simpler / smaller instances (that can be solved by recursive calls); then recombines the results of those subproblems; to produce the solution to the original problem; • a recursive function makes an algorithm easier to solve by breaking down the problem into manageable parts; and may use backtracking in an attempt to solve a subproblem; • direct or indirect recursion; eg (indirect) if fn A() calls fn B() and fn B() calls fn A(); • tail recursive is when recursive call is the last thing executed by the function; • when any function is called from A(), the memory is allocated to it on stack; • when a recursive function calls itself; the memory for the called function is allocated on top of memory allocated to calling function; • a different copy of local variables is created for each function call; • when the base case is reached, the function returns its value to the function from which it is called; memory is de-allocated (and the process continues); • an example of usage, eg a binary search is a recursive algorithm; expansion point; • examples of code/pseudocode // description of task;; • commenting/annotation of code/pseudocode;; A. Different wording with similar meaning A. Any other creditable answer 4 Question Guidance Mark 08 4 marks for AO2 1 mark for a partial description, 2 marks for a clear description, eg: • it is harder to quantify what is required from the outset / at the planning stage; the final outcome risks not being what as originally envisaged / risk of scope creep / experience rot; • the cost can be unpredictable (eg build-up of technical debt); delivering new functionality can increase the amount of unscheduled work (distracting the team from further progress); • more difficult to measure progress (eg than it is in Waterfall) because progress happens across several cycles; • the time / commitment / involvement required for testers / customers / developers / users to collaborate; eg clients need to be available for prompt sign-off / testing / feedback; • can be difficult to coordinate (large) teams/projects as the team has to be updated on each change; this makes it harder to work on separate parts (as that information has to be cascaded / changes to aspects such as class names might impact other parts etc); • can be frustrating for customers of the process; because development teams might struggle to give fixed dates across future iterations (but customers might have a requirement to align dependencies with those dates); • the need to train a client to aid in product development; (hard to quantify) so the project can easily fall off-track; • the advanced skill set required (problem solving / collaborative); which may have a cost implication (directly or indirectly, such as mentoring); • (less experienced) developers may struggle with the short cycles; which may not leave enough time for the design thinking process; • works around just in time (JIT) for development; so documentation is less detailed // less emphasis on design and documentation; • products lack cohesion / user journey is fragmented (because the design is fragmented); the more time passes, the more disjointed the software becomes; R. Similar expansion points A. Any other creditable answer 4 09 2 marks for AO4 1 mark for a partial/isolated point; 2 marks for a clear description/pairing. Example answers: Every module/class/function should have responsibility over a single part of the functionality (provided by the software); and that responsibility should be (entirely) encapsulated by the class; Modules/classes should be responsible for one (and only one) part of the functionality of a piece of software; This ensures that a class should only ever need to be changed for a single reason (when that core purpose alters); 2 Every module/class should have one (and only one) reason to change; if there are two reasons to change, the functionality has to be split into two classes; gathering together things that change for the same reason; separating things that change for different reasons; responsibility should be entirely encapsulated by the class; all its services should be narrowly aligned with that responsibility; Partial/isolated point: it refers to a module / class in object-oriented programming; a class should have one responsibility; it helps keep classes small and maintainable / easier to understand; A. Any other creditable answer Question Guidance Mark 10 6 marks for AO1 1 mark for each correct point or expansion point up to a maximum of 6 marks. Example answer: • Event-driven programming is when program execution is driven by events; • such as (a user) clicking on a mouse / pressing/touching a button within a GUI; • (when such an event occurs), a procedure is called to handle that event; • for example, a program to move a sprite around a screen might register to handle key press events; • (when the user presses a key, a function would be called) with the function being passed a parameter to indicate the key pressed; • Code in the function would check if the relevant key had been pressed and move the sprite accordingly; Examples include: • GUI is an interactive program that reacts to user input / events; • by triggering a (callback) function; • with the function being passed a parameter to indicate the key pressed; • the function will perform an action / interact with the user; example of action; • events are things like user actions / mouse clicks / keystrokes / sensor outputs / touchpads; on elements such as input boxes/buttons/lists on a GUI; • or window events such as resize/minimize/restore/close/switch tab; • code in the function would check if a relevant key had been pressed; • (functions might) also respond to (software / hardware) interrupts; • such as a timer interval; • network activity / file I/O; • or messages from/within other programs // JavaScript within HTML/CSS; • GUI allows programmers to write modular / independent code for the UI; which will respond to / be dependent on the events defined for them (in contrast to a CLI); • in event-driven programming a main loop listens for events; this code is known as an event listener; • in event-driven programming an output is dependent on an event that triggers/calls it; • example with expansion point(s): eg the command/function onchange (added to the SELECT tag) is the handler; which is triggered when the user selects an option / onchange is True; with the action determined by what is passed to the function; R. Similar points A. Any other creditable answer 6 Question Guidance Mark 11 4 marks for AO3 1 mark for each correct point or expansion point which explains workflow testing, up to a maximum of 4 marks. Maximum 3 marks if some misunderstanding evident. Examples include: • workflow testing is a type of functional testing; • implemented during the early stages of software testing; • which aims to improves the flow/efficiency of the processes; • each workflow process test reflects / mimics production environment / business process in testing environment; before it is deployed to the production/live environment; • (in order to conduct workflow testing) the business workflow must be thoroughly analysed / understood; • with test cases then developed and verified // must include sufficient test data (so each workflow can be tested thoroughly); • eg routing records through all possible paths // a series of paths, steps, stages; • with valid and invalid data; • (and then analysed) to show that expected output matches with the output derived from the test data; or else any deficiencies logged; • tests from user perspective / different types of user / client; to improve accuracy/effectiveness based on user type/role; • testing parts of system / integration testing; • (possibly) penetration testing workflow for security / capacity / performance; Phases: • inception phase which is initial testing & planning; • elaboration phase which includes baseline testing; • construction phase which includes (more significant) testing eg tests parts of system / integration tests / thorough testing of each stage; which allows the team to find any discrepancies or defects in the system or its workflow that was left undetected by the team earlier; • transition phase which involves regression tests / re-tests; • sequential or parallel stages eg checking the outcome matches test data; • compares expected vs actual results and logs defects; A. Any other creditable answer 4 Question Guidance Mark 12 8 marks for AO2 Maximum of 8 marks. Maximum 7 marks if any errors. Mark A for getting user input for walls and storing it in a variable; Mark B for appropriate prompts for each input (bullets 1 and 2); Mark C for a loop or similar (to gather inputs) for each wall; Mark D for correct loop conditions and increments; Mark E for getting user input for width and height; Mark F for using formula given in stem (for a wall or divide total once at end) Mark G for initialising a total variable and adding result of F to total; Mark H for outputting correct total (number of rolls needed based on number of walls) in an appropriate place; A. Mark H: • if total would be correct (ie the structure is appropriate) but for (D) loop conditions and/or increments being incorrect. • if candidate has assumed all walls are the same size. Example walls ← INPUT “How many walls?” total ← 0 FOR x = 1 TO walls INPUT w INPUT h total = total + ( w * h / 4.5 ) NEXT OUTPUT total A. maximum of 6 marks if an alternative to code/pseudocode is used (eg a flowchart) R. written descriptions which make no attempt to write as code/pseudocode. A. any style of pseudocode/syntax so long as the intention is clear. A. Any other creditable solution 8 Question Guidance Mark 13 6 marks for AO3 1 mark for each correct point or expansion point, up to a maximum of 6 marks. Examples include: • clear/concise/plain English writing; • availability in other languages // accessibility-adapted versions; • clear titles / section headings / consistent formatting; • (annotated) screen captures; • examples of coding are commented; • ease of navigation/search // table of contents / index; • integration of documentation into software application; • captures elements/features of software accurately/appropriately/and they are relevant; • updated for latest version of the software (screenshots, features etc); • use cases / links to related articles, examples; • troubleshooting section / other aid such as FAQ / glossary / tips and tricks; • created at the appropriate level / with the appropriate detail, eg lack of jargon / use only necessary technical terminology / use of shortcuts / use of screenshots; • technically/grammatically accurate; • keep it succinct, logical / show steps and sub-steps; applicable for target users/audience; • unambiguous; • accessibility (colours/fonts/assistive technology); • online vs printed; • instructions on how to install/set up the software in the first place; • include interactive elements with online/electronic documentation (eg hyperlinking); • video guides; with subtitles; • a dedicated online forum / support service; • tried out / tested with the user group / level; • system/technical guide and a (more straightforward/limited) user guide; R. similar points. A. Any other creditable answer 6 Question Guidance Mark 14 8 marks for AO4 Maximum 8 marks overall. Candidates may annotate the code, refer to line numbers or use any other method (including rewriting the code) so long as the point being made is valid and the intention clear. Maximum 5 from the following or any other creditable examples: • add comments; • combine line 01-03 into a=b=c=0 // a, b, c = 0, 0, 0; • combine lines 05-06 into a single print statement (using /n for a new line); (expansion) this reduces duplication of statements / reduces the risk of bugs / makes code maintenance easier; • line 18 does not need str (as a/b/c/ are all numeric); • use variable names that indicate the purpose of the variables; (expansion) valid examples; • declare variable names as global; (expansion) this helps to avoid confusion between the way different languages handle local/global variables; • use functions/subroutines to avoid repeated code (eg to handle asking a question and verifying the correct answer); and use a global variable to increment the score within the function (eg if score variable used/incremented throughout); • use lists/arrays/external file to store questions/answers; A. variables • use one variable/array rather than q1/q2/q3; • use loop or similar to loop through arrays (without repeating code); • use score variable instead of separate a, b, c variables; (and set to zero) and add 1 to the variable (for each correct question); (expansion) this makes code easier to read (because the purpose of the variable is obvious) // this makes the code more efficient / shorter; • check inputs are not blank (and loop back to input); • validate inputs to check for int/float // convert inputs; (expansion) and error handling to capture value errors; • format name input; • more options for validating correct answer (eg ‘two’ OR 2); • use +name+ (instead of ,name,) on line 5 (as this syntax is clearer/less confusing and is a string); • print/output comment if individual questions are correct // provide the correct answer; (expansion) the feedback (on which questions were answered incorrectly) could help learning; • allow user to try again // pause/press a key before going onto next question; • personalise further such as using name input at the beginning to congratulate (by name) at the end; Maximum of 4 expansion points;;;; A. coded solutions to examples given R. similar expansion points (eg only 1 mark overall for ‘shorter/more efficient’) 8 Question Guidance Mark 15.1 9 marks for AO3 9 Mark using the levels of response table and the indicative content on the following page. Level Description Mark Range 3 Clear understanding of both white box testing and black box testing with even coverage of both with clear comparisons made. 7–9 2 Some understanding of white box testing and black box testing across a range of points more even coverage towards the top of the range with some comparisons made. 4–6 1 Limited understanding of white box testing and/or black box testing (or a limited range of points). 1–3 No creditworthy material 0 Indicative content: Black box testing White box testing Testing, either functional or non- functional, without reference to the internal structure of the component or system, ie ‘like a black box inside which one cannot see’. Testing based on analysis of the internal structure of the component or system; also known as glass / transparent / open / clear box, or code- based / structural testing. Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non- functional, of a component or system without reference to its internal structure, eg testing webpage/verifying outputs against expected outcomes. Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system; checks internal functioning; chooses inputs, assumes the path of the logic in a unit / program is known, determines appropriate outputs. • Incorrect or missing functions. • Interface errors. • Errors in data structures or external database access. • Behaviour or performance errors. • Initialization and termination errors. • Test cases to cover entire code. • Testing beyond the user interface and into the detail of the system ‘engine’. • Can be tested at an earlier stage, eg pre-GUI. • Equivalence partitioning (valid/invalid partitions, selecting representative values as test data). • Boundary value analysis. • Generating test cases from cause- effect graphing (input and output conditions/effects). • Statement (each line of code) coverage. • Branch (from all decision points). • Condition/multiple condition coverage. • Cyclomatic (logical) complexity. • Loop testing. • Higher levels of testing based on requirement specifications; • focus (typically) on the behaviour of software. • Mainly acceptance/system testing; also unit, integration. • Lower levels of testing (typically) based on design detail; • code statements, branches, paths, conditions. • Mainly unit testing; some integration/system. • Testing against the known functions of the product; • ensures an expected output/outcome is achieved when providing certain input. • Many paths left untested / small number of inputs tested. • Developer creates tests to cover the various code paths to ensure code is working as expected; • determines all legal (valid and invalid) and illegal inputs and verifies the outputs against the expected outcomes. • (Independent) tester / from end user point of view / low level tester. • Programming/implementation knowledge / code access not required. • Tester (usually developer) / expert or experienced tester required. • Programming/implementation knowledge required / code access required. Question Guidance Mark 15.2 6 marks for AO3 Maximum 2 marks for each method/description. Examples include: • code coverage, eg percentage, logical pathways; test coverage describe the degree to which the source code of a program is executed when a particular test suite is run; • benchmark testing / run; for example comparing how fast the CPU in a laptop runs compared to an earlier model; • debugs tools eg: o watches; a watch pane updates variables with each step of the program; o step over – an action to take in the debugger that will step over a given line (and execute one line at a time); If the line contains a function the function will be executed and the result returned without debugging each line; o step into (which if the line does not contain a function is similar to step over); but if it does the debugger will enter the called function and continue line-by-line debugging there; o breakpoints; such as a line of code breakpoint when you know the region (but not necessarily exact point) of the problem // add breakpoints to an action rule and a decision table, and then run a debugging session to find and fix an error; o The Caché Debugger lets you test routines by inserting debugging commands directly into your routine code; such as breakpoints / watchpoints (which interrupt program execution); o inbuilt debugging tools such as those in Android Studio; (which allows you to select a device to debug your app on) and set breakpoints in your Java / Kotlin / C/C++ code // examine variables and evaluate expressions at runtime; o programming statements such as try-catch (C#) or try-except (Python); • selecting test data; and then comparing expected and actual results; • start from a known good start; and input until something breaks / bug observable; • focus on location of problem / bottom up perspective; check lower level functions work first / only change one variable at a time; • code inspection; • error detection is a feature of Intellisense; which can detect some errors (syntax/cryptic) as you type / before runtime; • crash logs/reports; which the developers can then analyse and use to debug; • create off-line models; • using the Internet / online forums/community etc; where someone is likely to have experienced/solved your error before; • alpha/open betas/closed betas etc; • (agile practice) pair/quad programming; partner more likely to see things you don’t notice; • outputting variables/strings etc at key points in the program; compare output with expected outcomes and debug from there; • commenting out certain sections // disabling certain functionality; this allows 6 the programmer to focus on the parts that are likely to have caused the problem / use process of elimination to find source of faults; R. similar expansion points R. white box / black box (Question 15.1) unless value added (0 marks for stating white box / black box, up to 2 marks for description) R. workflow testing (Question 11) unless value added (0 marks for stating method, up to 2 marks for description) A. Any other creditable answer Question Guidance Mark 16 15 marks for AO2 Mark using the levels of response table and the indicative content on the following page. Level Description Mark Range 5 The flowchart: 13–15 • solves the problem using appropriate flowchart symbols; • direction of flow is marked accurately, pathways are labelled (eg Y/N) and flowchart starts and terminates; • processes show clear understanding of program flow, and are labelled appropriately; • develops logical sequences; • identifies and develops implicit logic • makes fully appropriate decisions/loops; • counts the ingredients/jars out and/or in, eg variables set and change. 4 The flowchart: 10–12 • solves most of the problem • direction of flow is marked, pathways are labelled (eg Y/N) and flowchart starts or terminates • processes show clear understanding of program flow, and most are labelled appropriately; • develops some logical sequences; • identifies and begins to develop implicit logic; • makes appropriate decisions/loops; • counts most of the ingredients/jars out and/or in, eg variables set and change. 3 The flowchart: 7–9 • solves (or attempts to solve) most of the problem; • direction of flow is sometimes marked, some pathways are labelled (eg Y/N); • processes show understanding of program flow; • begins to develop logical sequences; • identifies some implicit logic; • makes some appropriate decisions/loops; • counts some of the ingredients/jars out and/or in, eg variables set and/or change. 15 Assessment Outcomes Question AO1 AO2 AO3 AO4 Question Total SECTION A 1 2d (1) 1 2 3a (1) 1 3 4a (1) 1 4 4a (1) 1 5 1c (1) 1 6 1a (3) 3 7 3ac (4) 4 8 2b (4) 4 9 4a (2) 2 10 1bc (6) 6 11 3d (4) 4 12 2e (8) 8 13 3h (6) 6 14 4a (8) 8 Total A 10 13 15 12 50 SECTION B 15.1 3d (9) 9 15.2 3d (6) 6 16 2d (15) 15 Total B 0 15 15 0 30 Totals 8 22 35 15 80