WA Computer Science ATAR Year 11 — Pseudocode and Algorithm Design Hangman

The 93 key terms

1program development life cycle

The four ordered stages that take a program from problem to working code: analysis, design, coding and testing. Planning before coding saves time.

2iteration

Making a version, testing it, getting feedback and improving it, then repeating the cycle until it does its job. Save numbered versions and change one thing at a time.

3Analysis

The first stage of the PDLC: work out exactly what problem must be solved and what the program must do, using abstraction and decomposition, before any design or code.

4requirement

A statement of something the program must do or provide so that the problem is solved. It is specific, comes from the problem and the user, and is used later to test the program.

5The 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.

6Non-functional requirement

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

7Coding stage

The third PDLC stage, where the design (pseudocode or flowchart) is turned into program code in a programming language, written step by step and checked against the requirements.

8abstraction

Keeping only the details needed to solve a problem and leaving out the details that do not matter, e.g. a map shows roads but not every tree.

9decomposition

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.

10Input, Process, Output, Storage

Read the scenario and sort every part into input (data in), process (what is done), output (result shown) or storage (data kept). Then check nothing is missing or in the wrong group.

11IPO 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.

12hierarchy chart

A diagram that splits one main problem into smaller sub-problems in boxes, level by level, until each box is a small task that can be solved on its own.

13Design stage

The second PDLC stage: plan the solution in detail using decomposition, structure diagrams, flowcharts and pseudocode, before any program code is written.

14structure diagram

Shows the parts of a solution as boxes. Flowcharts (pictures) and pseudocode (text) then show the steps of each box in order. Draw the structure diagram first.

15end if

A closing keyword in VCAA pseudocode that ends an if block; every nested construct uses end followed by its matching keyword: end if, end while, end for

17input

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

18print

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

19MOD

The pseudocode operator that returns the remainder after integer division. Example: 10 MOD 3 gives 1 because 10 divided by 3 is 3 remainder 1

21AND

A VCAA pseudocode boolean operator that combines two conditions. The overall result is true only when BOTH conditions are true. Example: x > 0 AND x < 10

22sequence

Steps that run one after another in a set order. Changing the order, leaving a step out or adding an extra step can change the result.

24IF-THEN-ELSE

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

25ELSE IF

A keyword that adds another condition to check if the previous IF or ELSE IF condition was false

26nested if

An if block written inside another if block. The inner condition is only checked when the outer condition is true. Indent the inner block and give each if its own end if.

27FOR 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

28WHILE condition DO

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

29REPEAT ... UNTIL condition

A loop that repeats its instructions and checks the condition after each repetition, so the body always runs at least once

30count <- 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.

31FOR / WHILE / REPEAT

Use FOR when the number of repeats is known, WHILE when the body might run zero times (such as reading until a sentinel), and REPEAT when the body must run at least once (such as validation).

32IF inside a loop

An IF or CASE placed in a loop body is tested again on every repeat, so each pass can take a different branch depending on the current value.

33Mixed iteration

Nesting one loop type inside a different loop type, such as a FOR loop inside a WHILE loop

34define

A keyword that starts a function definition, naming the function and listing the parameters it accepts

35addNumbers(a: INTEGER, b: INTEGER): INTEGER

A function header specifying the function's name, its typed parameters, and the data type of its return value

36return

A keyword that sends a value back from a function to where it was called, ending the function's execution at that point

37addNumbers(3, 4)

Calling a function by writing its name followed by arguments in brackets, running its instructions and possibly producing a value

38IPO 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.

39flowchart symbol

A fixed shape showing one step in a flowchart: oval start/end, arrow flow, rectangle process, parallelogram input/output, diamond decision, double-sided rectangle subroutine.

40flowchart sequence

A line of rectangles joined by arrows from the Start oval to the End oval, with one arrow in and one arrow out of each step. Each step is a short action phrase.

41decision diamond

A diamond shape in a flowchart that holds a yes/no question. One arrow labelled Yes and one labelled No lead to different steps, and the paths can join up again later.

43chained decisions

Putting one decision diamond after another, so a No arrow leads to the next diamond. This lets a flowchart choose between three or more paths, and every path reaches End.

44flowchart loop

An arrow that goes back to an earlier shape, usually from a decision diamond, so the steps repeat until the exit condition is met and the exit arrow is followed.

46REPEAT ... UNTIL

In a flowchart, the loop body comes first, then a decision. NO goes back to the body, YES leaves the loop, so the body runs at least once.

47FOR loop flowchart

Set Counter ← 1 in a process box, test Counter <= 10 in a decision, run the body on Yes, then do Counter ← Counter + 1 and flow back to the test. No leaves the loop.

48decision inside a loop

A diamond on the loop path is asked on every pass. Both its Yes and No branches rejoin, then go back to the loop test, usually after the counter update.

49step = shape

Each numbered step becomes one flowchart shape. An IF becomes a diamond, and a REPEAT becomes an arrow going back to an earlier shape. Both versions should do the same thing.

50flowchart to steps

Changing a flowchart into written steps: a diamond becomes IF or a loop condition, a back arrow becomes REPEAT, then check both versions do the same thing.

51follow an algorithm

To carry out each step exactly as written, in order, without skipping steps or guessing. You can track values on paper, check the final result, or act it out with a partner.

52dry 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.

53Trace table

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

54one 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.

55Trace table INPUT

A prompt is written in the OUTPUT column. The value the user types for an INPUT is written in that variable's column on that step, taken from the test data.

56OUTPUT column

The trace table column where you write each value or message shown by an OUTPUT statement, on the row where it happens. Text in quotes is copied exactly as the output.

57Counter ← 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.

58trace 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.

59condition column

A trace table column headed by a condition, such as age >= 13, that records TRUE or FALSE on each row so you can see which path the algorithm took and why.

60FOR Count ← 1 TO 5

To trace a FOR loop, give the loop variable each value from start to end in turn, run the loop body once for each value, and record every pass in its own row of the trace table.

61WHILE and REPEAT loop trace

Trace a loop by testing its condition each pass: WHILE tests before the body and may never run; REPEAT tests after the body so runs once at least. Stop when the loop ends.

62one row per pass

Trace an IF inside a loop with one row for each pass, showing the condition result (true or false) and any variables that change. The final row gives the output.

63Count ← Count + 1

Trace table for counting and totalling: Count and Total start at 0 in the first row, change each pass (Count only if the IF is true), and the final values are output after the loop.

64trace 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.

66trace 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.

67Execution order

The exact sequence in which an algorithm's lines run, followed step by step to trace its behaviour.

68purpose

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.

69first 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.

70score <- 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.

71trace 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.

72step 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.

73modify 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.

74logic error

A mistake in an algorithm's steps. It still runs to the end with no warning, but gives the wrong output. Only tracing or testing shows it, unlike a syntax error that breaks the writing rules.

75Age >= 18

Using > instead of >= (or < instead of <=) is a logic error: the boundary value, such as Age 18, is wrongly rejected. Test the boundary value, then correct the operator.

76Total ← 0

Set a total or counter to 0 before the loop. If you forget, it starts from an unknown value; if you put it inside the loop, it resets every time.

77off-by-one error

A FOR loop with the wrong start or end value runs one time too many or too few, e.g. TO 9 instead of TO 10, or starting at 0 for a 1-based array. Check the bounds with a trace table.

78wrong loop type

Using REPEAT when the body must sometimes not run, or WHILE when it must run at least once. REPEAT always runs once; WHILE may run zero times.

79Testing stage

The final PDLC stage: run the finished program with test data, compare results with expected results, check every requirement is met, and send any errors back to coding.

80test data

The input values chosen before testing, such as normal, abnormal, extreme and boundary values, used to run a program so its results can be compared with the expected results.

81Normal test data

A typical, valid value well inside the allowed limits, which the program should accept. Example: an age of 30 for a range check of 0 to 120 is accepted.

82Abnormal test data

Test data of the wrong type or outside the allowed values, such as -5 or letters for an age, or an empty input. The program should reject it.

83Boundary test data

The largest and smallest acceptable values plus the nearest rejected values either side of each limit, e.g. 0 and -1, 120 and 121 for a range of 0 to 120.

84normal, 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.

86expected 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.

87test table

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

88Pass 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.

89test 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.

90regression testing

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

91efficiency

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.

92Effectiveness

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.

93evaluation 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.

94requirements 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.

95apply 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.

96naming convention

An agreed pattern for naming variables, functions and controls so code is readable, consistent across a team and easier to maintain and debug.

97internal documentation

Comments inside the code, like a header with purpose, author and date, and notes on each function, that help others (or you later) understand and safely change the program.

98# array used because size is fixed

A comment that explains what a variable, array, record or algorithm is for and why it was chosen, rather than just repeating what the code does.

99header 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.

100external documentation

Documents supplied with a program: user documentation guides users to operate it; technical documentation records design (pseudocode, flowcharts, test results) for developers.