Searching, sorting, Big O notation · SDLC, testing, UI design · 108 terms
Click a topic above to jump straight in ↑
Search and sort algorithms, Big O notation, and trace tables.
7A finite, ordered set of unambiguous steps for solving a problem or performing a task.
A recipe: finite number of steps, in a specific order, clear instructions (not "add some flour" — "add 200g flour"). Algorithms must terminate (no infinite loops) and be precise.
A language-independent way of describing an algorithm using structured plain English/code-like notation.
Like writing instructions in plain English but in the style of code. Not actual Python, not just a sentence — somewhere in between. Used to plan algorithms before coding them.
A diagram that represents an algorithm using symbols and arrows to show flow of control.
A table used to follow the values of variables step by step as an algorithm/program runs.
Very common in Sections A and B. For each step, record the value of each relevant variable. Show every change, even tiny ones.
A search algorithm that checks items one by one until the target is found or the list ends.
Looking for your keys by checking every pocket, every drawer, one by one. No shortcut — just check everything in order until you find it.
A search algorithm for sorted data that repeatedly compares the target with the middle item and discards half of the remaining list.
Looking up a word in a dictionary. You open it in the middle — if your word comes before that page, you tear off the right half. Repeat. Much faster than checking page by page.
Binary search requires data to be sorted first. Complexity: O(log n).
The value being searched for in a search algorithm. Also called target or search value.
An algorithm that rearranges data into a specified order such as ascending or descending.
A simple sorting algorithm that repeatedly compares adjacent items and swaps them if they are in the wrong order.
Like bubbles rising in water — heavier values sink, lighter values bubble up. After each full pass through the list, the largest unsorted item has "bubbled" to its correct position at the end.
A sorting algorithm that repeatedly selects the smallest remaining item and moves/swaps it into its correct position.
Arranging a hand of cards by repeatedly finding the lowest card and placing it in the leftmost unsorted position.
A sorting algorithm that builds a sorted section by inserting each next item into its correct position within the already-sorted part.
How most people sort a hand of playing cards — you pick up each new card and slot it into the right place among the cards you're already holding.
A divide-and-conquer sorting algorithm that partitions a list around a pivot and recursively sorts the sub-lists.
Choose a middle value (pivot), put everything smaller on the left, everything larger on the right. Then repeat the process on each side. Divide and conquer.
The selected value used by quicksort to partition the list into lower and higher/equal values. A bad pivot choice can make quicksort inefficient.
Dividing a list into sub-lists based on comparison with a pivot during quicksort.
A way of describing how the time/number of operations needed by an algorithm grows as input size grows.
A notation for describing the growth rate of an algorithm's time or space requirements as input size increases.
The running time does not grow with input size. Example: accessing a list item by index.
Work grows slowly because the problem is repeatedly reduced by a factor — such as halving in binary search.
Work grows in proportion to the number of input items. Example: linear search worst case.
Work grows roughly with the square of input size, often from nested comparisons. Example: bubble sort.
Common efficient sorting complexity where the list is divided and each level processes all items. Example: quicksort best case / merge sort.
The input situation where an algorithm performs as efficiently as possible.
The input situation where an algorithm performs the maximum expected amount of work. Used most often for complexity analysis.
How well an algorithm or system uses resources such as time, memory, CPU or energy.
SDLC models, design, team roles, testing types, and user interfaces.
8A structured process for planning, designing, implementing, testing, deploying and maintaining software.
A software development process where phases are completed in sequence before moving to the next phase.
Like building a house: you must lay the foundation before the walls, walls before the roof. You can't go back easily. Structured but inflexible.
A flexible software development approach that builds software in repeated cycles/iterations, often with regular feedback.
Like sculpting clay — you build a rough shape first, then keep refining based on feedback. Requirements can change as you go. Good when you're not sure exactly what you need at the start.
A short, fixed period of work in agile development during which a team completes planned tasks.
Any person or group affected by or interested in a system, such as client, user, manager or developer.
The person or organisation requesting or paying for the software/system. Do not confuse with web client.
The person who will actually use the finished system. Important in user-centred design.
A statement of what a system must do or how it must perform. Divided into functional and non-functional.
A requirement describing what the system must do, such as "calculate totals" or "save user records."
A requirement describing how well the system should perform, such as usability, speed, reliability, security or accessibility.
Functional = what it does. Non-functional = how well it does it.
Role responsible for planning, resourcing, scheduling, monitoring progress and communication.
Role that investigates the problem, gathers stakeholder requirements and documents what the system should do.
Role that plans how the system will work/look, using tools such as flowcharts, pseudocode, wireframes and database design.
Role that writes, tests, debugs and modifies program code.
Role that tests software, records results and helps find faults before release.
Role that defines the overall structure, components, protocols and technology stack of a system.
Role focused on creating a usable, accessible and pleasant user interface/user experience.
A low-fidelity sketch/diagram showing the layout and structure of a webpage or interface — no real content or full styling.
An architect's rough floor plan before the detailed blueprints. Shows where rooms go, not what colour the walls are.
A simplified working or partly working version of a system used for testing, demonstration or feedback. Higher fidelity than a wireframe.
Designing a system around the needs, goals, abilities and feedback of its users.
The means by which a user interacts with a computer system and receives output from it.
The overall experience a user has while using a system, including ease, efficiency, satisfaction and accessibility.
An interface using visual elements such as windows, icons, menus and pointers/touch. WIMP is associated with GUI.
A text-based interface where users type commands to interact with the system. Requires knowledge of commands.
An interface where users choose from displayed options/menus. Common in kiosks and ATMs.
An interface where users interact by touching a screen. Common in smartphones and kiosks.
An interface where users interact using spoken commands. Used in smart speakers and voice assistants.
Designing products/environments to be usable by as many people as possible without needing special adaptation.
Know the principles: equitable use, flexibility in use, simple & intuitive, perceptible information, tolerance for error, low physical effort, size and space.
Designing systems so people with different needs/abilities can use them effectively.
Examples: screen readers for visually impaired, high contrast modes, keyboard navigation for those who can't use a mouse.
Technology that helps a person with a disability or additional need to use a computer/system. Examples: screen reader, braille display, voice recognition.
Technology that is modified or configured to suit an individual user's needs.
A specific input/action and expected result used to check whether code or a system works correctly.
Testing small individual units/components/functions of code, usually by the developer.
Testing that multiple components work correctly together.
Testing the whole system to check whether it works as intended under realistic conditions.
Testing whether system features meet their functional requirements from the user's perspective.
Testing qualities such as performance, usability, reliability, security, compatibility or scalability.
2023 exam: distinction between functional and non-functional testing. Know the difference!
Retesting existing functionality after changes to ensure new changes did not break working code.
After renovating your kitchen, you check that the living room still works — the renovation shouldn't have broken anything elsewhere.
Testing based on inputs and expected outputs without knowing internal code structure.
Testing with knowledge of the internal code/logic, often to cover execution paths.
Written/visual material explaining code, design, testing, use or development of a system.
A system for tracking changes to files/code over time, allowing collaboration and recovery of previous versions.
Like Google Docs' version history — you can see who changed what and when, and roll back to an earlier version if something goes wrong. Git is the most common version control system.
SDLC models, design, team roles, testing types, and user interfaces.
8A structured process for planning, designing, implementing, testing, deploying and maintaining software.
A software development process where phases are completed in sequence before moving to the next phase.
Like building a house: you must lay the foundation before the walls, walls before the roof. You can't go back easily. Structured but inflexible.
A flexible software development approach that builds software in repeated cycles/iterations, often with regular feedback.
Like sculpting clay — you build a rough shape first, then keep refining based on feedback. Requirements can change as you go. Good when you're not sure exactly what you need at the start.
A short, fixed period of work in agile development during which a team completes planned tasks.
Any person or group affected by or interested in a system, such as client, user, manager or developer.
The person or organisation requesting or paying for the software/system. Do not confuse with web client.
The person who will actually use the finished system. Important in user-centred design.
A statement of what a system must do or how it must perform. Divided into functional and non-functional.
A requirement describing what the system must do, such as "calculate totals" or "save user records."
A requirement describing how well the system should perform, such as usability, speed, reliability, security or accessibility.
Functional = what it does. Non-functional = how well it does it.
Role responsible for planning, resourcing, scheduling, monitoring progress and communication.
Role that investigates the problem, gathers stakeholder requirements and documents what the system should do.
Role that plans how the system will work/look, using tools such as flowcharts, pseudocode, wireframes and database design.
Role that writes, tests, debugs and modifies program code.
Role that tests software, records results and helps find faults before release.
Role that defines the overall structure, components, protocols and technology stack of a system.
Role focused on creating a usable, accessible and pleasant user interface/user experience.
A low-fidelity sketch/diagram showing the layout and structure of a webpage or interface — no real content or full styling.
An architect's rough floor plan before the detailed blueprints. Shows where rooms go, not what colour the walls are.
A simplified working or partly working version of a system used for testing, demonstration or feedback. Higher fidelity than a wireframe.
Designing a system around the needs, goals, abilities and feedback of its users.
The means by which a user interacts with a computer system and receives output from it.
The overall experience a user has while using a system, including ease, efficiency, satisfaction and accessibility.
An interface using visual elements such as windows, icons, menus and pointers/touch. WIMP is associated with GUI.
A text-based interface where users type commands to interact with the system. Requires knowledge of commands.
An interface where users choose from displayed options/menus. Common in kiosks and ATMs.
An interface where users interact by touching a screen. Common in smartphones and kiosks.
An interface where users interact using spoken commands. Used in smart speakers and voice assistants.
Designing products/environments to be usable by as many people as possible without needing special adaptation.
Know the principles: equitable use, flexibility in use, simple & intuitive, perceptible information, tolerance for error, low physical effort, size and space.
Designing systems so people with different needs/abilities can use them effectively.
Examples: screen readers for visually impaired, high contrast modes, keyboard navigation for those who can't use a mouse.
Technology that helps a person with a disability or additional need to use a computer/system. Examples: screen reader, braille display, voice recognition.
Technology that is modified or configured to suit an individual user's needs.
A specific input/action and expected result used to check whether code or a system works correctly.
Testing small individual units/components/functions of code, usually by the developer.
Testing that multiple components work correctly together.
Testing the whole system to check whether it works as intended under realistic conditions.
Testing whether system features meet their functional requirements from the user's perspective.
Testing qualities such as performance, usability, reliability, security, compatibility or scalability.
2023 exam: distinction between functional and non-functional testing. Know the difference!
Retesting existing functionality after changes to ensure new changes did not break working code.
After renovating your kitchen, you check that the living room still works — the renovation shouldn't have broken anything elsewhere.
Testing based on inputs and expected outputs without knowing internal code structure.
Testing with knowledge of the internal code/logic, often to cover execution paths.
Written/visual material explaining code, design, testing, use or development of a system.
A system for tracking changes to files/code over time, allowing collaboration and recovery of previous versions.
Like Google Docs' version history — you can see who changed what and when, and roll back to an earlier version if something goes wrong. Git is the most common version control system.