QCE Digital Solutions Unit 1 — Programmed Solutions Hangman

The 96 key terms

1The solution must

Starts a functional requirement: one thing a digital solution must do. It says what the solution does, not how, and covers one action. Example: The solution must show the score.

2Non-functional requirement

A quality describing how well a system performs, such as speed, security, or reliability, rather than what it does

3IPO chart

A table with Input, Process and Output columns that lists what the user enters, the calculations and decisions the code makes, and the results or messages it displays.

4decomposition

Splitting a big problem into smaller sub-problems, such as input, process and output. Each part can be solved on its own, then the solutions are combined.

5Proof-of-concept, Prototype, Product

Three progressive stages of solution development: proof-of-concept tests feasibility, prototype demonstrates function, and product is the final polished release

6IPO to pseudocode

Turn each IPO input into an INPUT statement, each process into assignments or IF selection, and each output into a PRINT statement, in that order.

8input

A VCAA pseudocode keyword that accepts a value from the user and stores it in a named variable. Example: input age stores the user's entered value in the variable age

9print

A VCAA pseudocode keyword that outputs a value, variable or expression as a result. Example: print area displays the current value stored in the variable area

10IF-THEN-ELSE

A selection structure that runs one set of instructions if a condition is true, and a different set if it is false

11FOR i FROM 1 TO n

A loop that repeats its instructions a fixed number of times, counting the variable i from 1 up to n

12WHILE condition DO

A loop that repeats its instructions for as long as the given condition remains true, checked before each repetition

13count <- count + 1

A counter. It adds 1 to a variable each time a loop repeats. Set it to 0 before the loop. An accumulator works the same way: total <- total + x adds a value each time.

14program

A text file of Python instructions. You write it in the editor, and when you press Run, Python does each line in order from first to last and shows the output in the output panel.

35while not valid:

A loop that keeps asking for input again until the answer is valid, so bad data (like an age of -5) can't get into your program. Show an error message each time.

39for item in my_list:

Runs the indented block once for each value in the list. The variable item holds the current value each time round, starting with the first and finishing with the last.

45def main(): greet()

A function can call another function inside its body. Big problems get split into small helper functions that each do one job, like boxes in a decomposition.

46def main():

Defines a function called main that holds the main steps of your program. You call main() once at the end of the file, after the other functions are defined, to start the program.

47score <- 0 becomes score = 0

Pseudocode steps map to Python lines: <- becomes =, input becomes input(), if becomes if with a colon, for becomes for in range(). END IF becomes un-indenting.

48root = tk.Tk()

Creates the main tkinter window after import tkinter as tk. Call root.mainloop() at the end to show the window and wait for events like clicks.

49tk.Label(root, text='...')

Creates a tkinter label that shows text in the window. Use .config(text=...) to change what it shows, such as displaying a result. Options like font and fg set style.

50entry = tk.Entry(root)

Creates a text box in the window. Call entry.get() to read what the user typed. It is always a string, so convert it with int() or float() to use it as a number.

51tk.Button(root, text='Go', command=show)

Makes a button that runs the function show when clicked. Write the function name with no brackets, or it runs straight away instead of on click.

52control.grid(row=0, column=1)

Places a control in a table-like layout at the given row and column. pack() instead stacks controls in order. Never mix grid and pack in one window.

53messagebox.showinfo()

Pops up a message window to tell the user a result. Its partner messagebox.showerror() pops up an error, such as when a handler finds invalid input. Both need a title and a message.

55library

A collection of ready-made code you can reuse. The standard library comes with Python; third-party libraries are made by others and must be installed separately (e.g. with pip).

56import math

Loads Python's math module, giving you extras like math.sqrt(), math.pi, math.ceil() and math.floor() that basic operators don't have. Call them with the math. prefix.

57import random

Gives your program the random module. Then random.randint(1, 6) gives a random whole number from 1 to 6, and random.choice(my_list) picks a random item from a list.

58# Source:

A comment placed above code you reused that names the source (such as a URL), the author and the licence, so the original work is credited and your own lines are clear.

59modify code

Read and trace the code first to see what it does, then change one small part at a time and re-run your test cases to check the effect of that change.

60normal, boundary and invalid data

A good test set uses normal data (typical values), boundary data (values at the edges of a range) and invalid data (values that should be rejected), so every path in an algorithm is checked.

61test data

Values chosen to test each validation rule: empty for existence, text for type, and values just inside and just outside range limits, each with an expected result.

62expected output

The correct result of a test case, worked out by hand from the specification before running the code. Never copy it from the program's own output, or the test proves nothing.

63test table

A table with one row per test case. Its columns are test number, purpose, input, expected result, actual result and pass or fail.

64test case

A chosen input paired with the output you expect. Run the program with it, compare the real output to the expected result in your test table, then record pass or fail.

65input()

Pauses a program so you can type a test value; it returns text. Test by typing each planned input in order, then compare the printed output with the expected result.

66Pass or Fail

Copy the actual result exactly as the program gave it, then mark Pass only if it matches the expected result, otherwise Fail. Never change the expected result to fit, and add a note for fails.

67assert

Checks a condition is True, like assert add(2, 3) == 5. If the result is not what you expected, it raises an AssertionError, so test cases can run automatically.

68unit testing

Testing one function or class on its own, with its own test table, before joining it to the rest of the program, so a failing test points to that module.

69test coverage

Testing so that every if/elif/else branch runs at least once and every loop is tried running zero times, once and many times. Any code never run is untested.

70alpha testing

Testing run by the developer during development to check the solution meets requirements and works correctly, so errors are found and fixed before beta testing with users.

71dry run

Working through an algorithm by hand, line by line, using chosen test data as inputs and recording each step in a trace table, to see what it does and find logic errors without running it.

72Trace table

A table that records the value of each variable at every step of an algorithm, used to check its logic by hand.

73one column per variable

To set up a trace table, give each variable its own column in the order they first appear, then add a row each time a value changes. Leave unchanged cells blank.

74Counter ← Counter + 1

When tracing, work out the right side using the current values, then write the result in that variable's column. The old value is used first, then replaced by the new one.

75trace an if

Check the condition using the current values, record TRUE or FALSE in the trace table, then follow only the branch that is true and skip the other branch.

77nested loop

A loop inside another loop. When tracing, the inner loop completes all its repeats for each single repeat of the outer loop, so total passes = outer repeats x inner repeats.

78trace a compound condition

Work out each part as TRUE or FALSE for the current values, record both in the trace table, then combine them with AND, OR or NOT. Do brackets first.

79trace a flowchart

Follow a flowchart from Start to Stop using test values, noting each diamond's Yes or No answer in a trace table and following loop arrows back until Stop.

80purpose

What the whole algorithm achieves. Follow the steps, check what it SHOWS and read the variable names for clues, then say it in one sentence.

81trace vs output

Run the code with the same input you traced, then compare. If the real output differs from your trace, either the trace or the code has a mistake, so re-trace.

82first wrong value

In a trace table, the first row where a value differs from what you expected points to the faulty line of the algorithm. Look at that line, then suggest a correction.

83syntax error

An error that occurs when Python cannot understand your code due to a typo, missing quote, or wrong bracket; Python stops and shows a message with the line number

84IndentationError

Python errors when a block's lines are not indented consistently, or when the if, for, while or def line that opens the block is missing its colon.

85Traceback (most recent call last):

The start of Python's error report. It names the error type (like NameError) and the line number where it happened, so you know where to start looking for the bug.

86runtime error

An error that stops a program while it runs, shown as a named error like NameError, ValueError or ZeroDivisionError. Read the message to find the problem.

87NameError

An error Python raises when code uses a variable or function name it does not know, often from a typo, wrong capitals, missing quotes or using a name before it is assigned.

88TypeError

A runtime error when an operation gets the wrong data types, like '5' + 3 (string plus integer). Fix it by converting with int() or str(), e.g. int(input()).

89ZeroDivisionError

A Python runtime error raised when a number is divided by 0, or a remainder is taken with % 0. Guard against it with an if check or try/except.

90IndexError

A runtime error raised when code uses an index that is not in the list, such as items[5] in a 5-item list. The last valid index is len(items) - 1.

91infinite loop

A while loop whose condition never becomes False, often because the loop variable is never updated. Stop it with the Stop button, or fix it by changing the variable inside the loop.

92logic error

A mistake that lets a program run with no error message but give the wrong result, caused by a wrong condition, operator (> or >=), range() off by one, or steps in the wrong order.

93return

Sends a value back to the caller. If a function only prints and has no return, it gives back None, so the caller cannot use the result.

94error in an algorithm

A mistake that breaks pseudocode rules or gives wrong results. Find it by reading the code, then trace it with test values and compare the actual output with the expected output.

95print("total =", total)

A debug print. Add a line like this to show a variable's value while the program runs, so you can spot where it goes wrong. Put one inside a loop to watch it change, then remove it once fixed.

96# (commenting out)

Putting # in front of a line, or a selected block, stops Python running it. Use this to isolate a bug, then remove the # to restore the code.

97breakpoint

A marker set on a line of code that pauses the program there when it runs, so you can inspect variables and step through. Set one by clicking beside the line; click again to remove it.

98step over

Run the next line only, then pause again. Check the variable watch panel after each step to see which line first gives a wrong value.

99black-box testing

Running unfamiliar code with chosen inputs and recording the outputs to infer what it does without reading the source. The evidence only covers the inputs you tried.

100corrective action

The fix recorded in a testing table for a failed test, followed by the retest result that shows whether the fix worked (pass or fail).

101regression testing

After fixing a bug, rerun the failed test and all earlier tests, because a fix can break code that used to pass.

102efficiency

How well a solution uses resources such as time, processing, memory, storage and user effort to do its job. An efficient solution is fast, light on memory and storage, and saves the user time.

103Effectiveness

How well a solution does what it was meant to do, giving correct, complete and usable results that meet the requirements and suit its purpose.

104algorithm efficiency

How many steps an algorithm takes as data grows, and what it needs (e.g. sorted data for binary search). Compare it to choose between linear or binary search, selection or quick sort.

105programming languages to be used

A brief feature naming the language(s) the solution will be built in, with a reason, such as suiting the platform, the developer's skills or the libraries available.

106compiler vs interpreter

A compiler translates the whole program into an executable before it runs; an interpreter translates and runs line by line, stopping at the first error, with no executable.

108usability

How easily, quickly and accurately users can learn and use software to achieve their goals, including ease of learning, efficiency of use, and error prevention and recovery.

109accessibility feature

A design choice that lets people with different abilities use a system, such as alt text for images, captions for video, keyboard-only controls or colour-blind safe colours.

110feedback

A response from the interface that tells the user what happened, like a confirmation message, or an error message that says what went wrong and how to fix it.

111Annotated design review

Checking a mock-up against each UI principle in turn (alignment, balance, contrast, space, text), annotating the improvements needed, then revising the design.

112useability principles

Criteria for judging a prototype's interface: accessibility, effectiveness, error tolerance, ease of learning and engagement, rated using evidence from a user trial.

113evaluation criterion

A measurable target for efficiency or effectiveness, such as 'search returns in under 2 seconds', that can be checked after development to judge whether the solution succeeded.

114requirements checklist

A list of every functional requirement and success criterion. You test the solution against each one, then record yes or no and note your evidence, such as what you saw or a screenshot.

115apply evaluation criteria

Gather evidence for each criterion, compare it with the target, then judge if it is met or not met, for both efficiency and effectiveness.

116evaluation report

A document that states how well each criterion was met, gives evidence for each conclusion, and recommends improvements to the solution.

117naming convention

An agreed pattern for naming variables, functions, classes and constants so code is consistent, uses meaningful names and is easy to read.

118snake_case

A naming style where all letters are lowercase and words are joined by underscores, like student_score. Python uses it for variables and functions, and it should be used consistently.

119internal documentation

Explanation written inside the code to say what it does and why, so other programmers can understand, fix and update it later.

120scores = [] # marks for each student

A comment beside a variable, list, record or class that says what it stores and how it is used, so other programmers can understand the data and code structures.

121"""docstring"""

A triple-quoted string placed first in a function or class that describes its purpose, parameters and return value. It is internal documentation.

122header comment

A comment at the top of a file that records the program's purpose, author, date and any changes made, so others can understand and maintain the code.

123readable code

Code that people can quickly understand, using clear names, consistent indentation and spacing, short functions with no repeated code, and helpful comments.

124maintainable code

Code organised so it can be fixed or extended later without breaking other parts, using small functions, classes that hide detail and constants instead of repeated values.

125refactoring

Rewriting working code to make it clearer or simpler (e.g. renaming variables, moving repeated lines into a function) without changing what it does, then re-running tests.

126community impact

How a digital solution affects other people, not just its user. It can help (benefits), cause problems (harms), or leave some people out.

127future impact

How a solution could affect society, the economy and the environment over time, including unintended effects its designer did not plan for.

128Ethical issue

A situation where a design or technology choice could unfairly harm, exclude, or disadvantage people, even if it is legal