VCE Software Development - U4O1 - development and evaluation Hangman

The 148 key terms

1efficiency

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.

2Effectiveness

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.

3user-centred design

Designing a solution around the needs of its real users, by finding out what they need and involving them throughout development, using their feedback to revise the design.

4user experience (UX)

How easy, efficient and pleasant a system feels to use from start to finish, not just how it looks. Good UX avoids frustration points, while UI is only the look.

5usability

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.

6feedback

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.

9GST_RATE = 0.1

A constant: a named value set once and never changed while the program runs. Written in UPPER_CASE by convention, it replaces magic numbers and is easy to update in one place.

11global

A keyword used inside a function so it can assign to a variable defined outside all functions, instead of creating a new local variable with the same name.

21sequence

A control structure where statements run one after another, top to bottom, so changing their order can change the result.

25nested if

An if statement indented inside another if block. The inner condition is only checked when the outer condition is True.

29Nested FOR loop

A FOR loop placed entirely inside another FOR loop, so the inner loop runs fully for every repetition of the outer loop

31count += 1

Set count = 0 before a loop, then use count += 1 inside it to add 1 each repeat. Use total += value to build a running total.

32one-dimensional array

A named, ordered collection of elements of the same data type. Each element is reached by its index, its position number (0-based in Python, often 1-based in pseudocode).

35for 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.

36for i in range(len(arr)):

Loops i through every index of arr, so arr[i] can be read or changed and you know each element's position. Used for totals, finding the largest value and editing in place.

37grid[row][col]

A 2D array stores data in rows and columns like a table. Use the row index first, then the column index, to reach one element, such as a seat in a seating plan.

43record

A data structure that groups related fields of different data types into one item describing one thing, e.g. a student's name (String), age (Integer) and enrolled (Boolean).

44student['name']

Gets a field from a record by its field name. A list or tuple record uses the field index (its position) instead, such as student[0]. Indexes start at 0.

46list, dict, tuple

Pick the structure by how you use the data: a list for an ordered collection, a dict for lookup by key, and a tuple for a fixed group of values that should not change.

47int(input())

input() always returns a str, so convert it (e.g. with int) to store it as a number. Turn it back into text with str() or an f-string when you output it.

48TXT file

A plain text file holds unformatted characters, usually one line of text per line ended by a newline. It has no field headings or data types, so everything is read as a string.

49CSV

A text file with one record per line, fields split by a delimiter such as a comma, and an optional header line of field names. Text containing commas goes in quotes.

50<student><name>Mia</name></student>

XML stores data in nested, named elements. Each element has an opening and closing tag, and child elements sit inside a root element. The tags describe the data.

51TXT, CSV, XML

Choose a data source by structure: TXT for simple lines, CSV for tables of records, XML for nested self-describing data shared between systems. All three store data between runs.

55line.split(',')

A string method that breaks a line of text into a list of field strings at each comma. Use strip() first to remove the newline, and int() or float() to convert fields.

56records.append(line.strip().split(','))

Splits one CSV line into fields and appends them as one record to a list, so each row of the file becomes a record and the whole file becomes a table in memory.

57','.join(record)

Joins a record's fields, which must all be strings, into one comma-separated line. Use str() on numbers first, then write the line plus a newline to the CSV file.

58xml.etree.ElementTree

Python module that parses an XML file into a tree of elements. Use find() and findall() to reach elements and .text to read their values.

64procedure vs function

A procedure carries out a task without returning a value, while a function returns a value to the code that called it, so the result can be stored or used.

65def main():

A function that calls other small functions, each doing one job, so the program is built in parts. Each box in a hierarchy chart can become one function.

75objects.append(obj)

Adds an object to the end of a list so many objects are stored together. You can then loop over the list with a for loop to call each object's methods or find one by its attribute.

76self.name

A public member has no leading underscore, so code inside or outside the class can access it, e.g. self.name in the class or pet.name outside it.

77_name

A single underscore prefix marks a protected member: by convention it is for use inside the class and its subclasses only. Python does not enforce it, so outside code can still access it.

78self.__name

A private attribute: the double underscore makes Python name-mangle it, so code outside the class cannot reach it directly and gets an AttributeError.

79@property

A decorator above a getter method. It lets outside code read a private attribute like a normal attribute, such as obj.name, with no brackets. With no setter, the attribute is read-only.

80encapsulation

Bundling an object's data and methods together and restricting access, so private data is only changed through public methods that can check values are valid.

81def set_age(self, age):

A setter method that checks a new value (such as a valid age range) before storing it in a private attribute, rejecting or reporting bad values so the object never holds invalid data.

82access modifier

Marks a class member as public (name), protected (_name) or private (__name), so the class exposes only what other code needs.

83abstraction

Modelling only the attributes and methods that matter for a purpose and hiding the rest of the detail, such as a Student class that keeps just the data a school app needs.

85super().__init__()

Runs the parent class's __init__ first so it sets up inherited attributes, then the child's __init__ adds its own extra attributes.

86GUI

A graphical user interface: windows and controls like buttons and text boxes the user clicks or types in. The program waits for events, such as a click, and responds to each one.

87root = 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.

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

89entry = 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.

90tk.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.

91control.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.

92StringVar()

A tkinter variable that stores the user's pick from a choice control (Checkbutton, Radiobutton or Combobox). Link it with variable= and read the choice with .get().

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

94readable code

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

95naming convention

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

96snake_case

A naming convention that writes every letter in lower case and joins words with underscores, e.g. student_first_name. Python uses it for variables and functions.

97studentFirstName

Camel casing: join words with no spaces, start with a lower case letter, then capitalise the first letter of each later word, e.g. studentFirstName or calculateTotal.

98Hungarian notation

A naming style where a variable name starts with a short lower-case prefix showing its data type, e.g. strName, intAge, fltPrice, blnPassed.

99btnSubmit

Hungarian notation for a control: a type prefix (btn button, txt textbox, lbl label, lst list, cbo combobox) plus a purpose, so btnSubmit is clearly a button.

101sum(), min(), max()

Built-in functions that return the total, smallest and largest value in a list, replacing a hand-written loop with one short, clear line of code.

102[x for x in items]

A list comprehension builds a new list from a loop in one expression. Add 'if condition' to filter items, or change x (e.g. x * 2) to transform each item.

103refactoring

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.

104maintainable 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.

106internal 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.

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

108# 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.

109"""docstring"""

A triple-quoted string on the first line of a function or class body. It documents what the code does, its parameters and its return value. help() displays it.

110pass

A Python statement that does nothing. It fills a stub's empty body, often beside a # TODO comment, so the program still runs while the real code is written later.

111version control

A system that records every change to project files, so developers can see who changed what, work in parallel on branches, and roll back to an earlier version.

112repository

A storage location for a project's files and full change history. It can be local or remote (e.g. GitHub), lets a team share code, and keeps a backup of every version.

113git commit -m "message"

Records a snapshot of the files you staged with git add, saving it in the repository history with a short message that explains what changed.

114git clone, git push, git pull

clone copies a remote repository to your computer; push uploads your commits to the remote; pull downloads other people's new changes into your copy.

115git branch

Creates a branch, a separate line of development that you work on safely and later combine into the main branch with git merge.

116library

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).

117import 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.

118import 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.

119from datetime import datetime

Brings in the datetime tool so Python can get the current date and time with datetime.now(), format it with strftime, and subtract two dates to find a duration.

120pip install requests

A terminal command that uses pip to download a third-party library (here requests) so a Python program can then import it. Add ==2.31.0 after the name to pick a version.

121API

An application programming interface: a defined set of requests and responses that lets one program use the features or data of another program.

122requests.get(url)

Sends a request to a web API endpoint at the given URL and returns a response object. Needs import requests. Check response.status_code (200 means success) before using the data.

123response.json()

Converts the JSON text of an API response into Python dictionaries and lists, so you can read values by key, e.g. data['name'], or loop over a list of results.

124response.status_code

Check a response's status code (200 OK, 404 not found) and wrap requests.get() in try/except so a failed API call shows a friendly message, not a crash.

125API key

A secret code that identifies your program to an API. Keep it in a separate file, out of the repository and shared code, because it is linked to your usage limits.

126AI code generation

Using AI tools, like editor assistants and chatbots, to turn plain-English prompts into program code. It saves time, but the code must still be checked and tested by the programmer.

127code prompt

A clear AI request stating the language, the task, the inputs and outputs, and the constraints. Keep to one task per prompt, e.g. Write a Python function that returns an average.

128follow-up prompt

A new prompt sent after reviewing AI code that names the exact problem, e.g. 'Use snake_case names and add range checking', so the next version fixes it.

129Verify AI-generated code

Read and trace AI code, then test it with your own boundary and invalid data, and check it meets the requirements. It can look right but be wrong or use made-up functions.

130AI debugging

Giving an AI tool your code, the error message and the expected behaviour so it suggests a cause and a fix, which you must still understand and test yourself.

131assert

AI can draft assert tests for a module, but you must check each expected output by hand to be sure it is correct. Also add any normal, boundary or invalid cases it missed.

132optimisation

Changing code so it runs faster, uses less memory or is easier to read, without changing what it does. For example, removing repeated code or using a built-in function.

133regression test

Re-running the same test cases on AI-optimised code to prove it still gives identical results as before. If any result changes, reject the change.

134confidential data

Private information like personal data, passwords or secret code. Never paste it into an AI tool, as it may be stored or used to train the model. Use fake sample data and check the data policy.

135# AI-generated: ChatGPT

A comment that acknowledges AI helped write the code. Name the tool and prompt, and check the output is not copied licensed work. You stay responsible for the final code.

136AI over-reliance

Trusting AI-generated code without checking it. The code may be biased, outdated or insecure, and you lose your own skills and judgement. Always review it and stay in control.

137validation vs verification

Validation checks entered data is reasonable and complete. Verification checks it matches the source data, for example by proofreading.

138if value.strip() == '':

An existence check tests that a value was actually entered. strip() removes spaces, so this is True for empty or space-only input, and an error message can be shown.

139type check

A check that input is the expected data type, using .isdigit(), try/except around int() or float(), or isinstance(). input() is always text, so check before converting.

1401 <= age <= 120

A range check: tests that a number lies between a minimum and a maximum (inclusive here). Values outside the limits, such as 0 or 121, are rejected as invalid.

142while 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.

143def is_valid_age(text):

A validation function that runs the existence, type and range checks in order and returns True or False, so the same checks can be reused for many inputs and tested.

144syntax 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

145runtime 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.

146logic 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.

147Traceback (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.

148IndexError

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.

149TypeError

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()).

150ZeroDivisionError

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.

151alpha 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.

152print("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.

153Trace table

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

154breakpoint

A marker set on a line of code (click beside the line number) that pauses the program there in debug mode, so you can inspect variables and step through the code.

155step through

Run paused code one line at a time using step over, step into or step out, while the watch panel shows each variable change, to find where a value goes wrong.

156# (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.

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

158Boundary values

Test inputs at the edge of a condition. For age >= 18, test 17 (just below), 18 (exactly on) and 19 (just above) to check the algorithm picks the right path at the edge.

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

160test case

A chosen input paired with the output you expect. Run the algorithm, record the actual output, then compare: if actual matches expected it passes, otherwise it fails.

162corrective 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).

164unit 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.

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

166beta testing

Testing where potential users try the near-finished solution to check it meets requirements and is usable. It follows alpha testing, which is done by the developers.

167User testing

A testing technique where real users try a solution and give feedback, helping identify usability issues before release

168core feature

A main function users most need to work. A beta test focuses on these first, linked to the requirements, before minor extras.

169beta testers

Potential users who represent the intended audience and test software before release. Choose at least two, such as other students, so feedback comes from real users.

170beta testing plan

A plan that states which features will be tested, who the testers are, when testing happens and how the results are collected and recorded.

171test scenario

A realistic task a beta tester performs with the solution, written as a task description, steps to follow and a clear expected outcome to check the result against.

172observe without helping

Watch testers complete a scenario without helping them, and note where they hesitate, make errors or succeed, so you can see real usability problems.

173Beta test results

A record of each beta test scenario, what happened, the tester's comments and any issue found, so the developer can decide what to fix.

174recommend modifications

Group similar beta test issues, rank them by impact, then suggest a specific change for each one that links back to a requirement of the solution.

175Evaluation criteria

Measurable standards used to judge how well a finished solution meets its original requirements and purpose

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

177time frame

The part of an evaluation strategy that states when the solution will be evaluated and when data will be collected, such as set dates or a timeline.

178responsibility

The part of an evaluation strategy that names who collects the data and who judges each criterion, so every task has a clear owner.

179evaluation strategy

A plan listing the data to collect, the method used to collect it (such as a survey, test or observation) and which evaluation criterion each piece of data will help you judge.

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

181refine evaluation criteria

Review and reword evaluation criteria as the solution develops, so they stay measurable and relevant, such as making vague wording specific or updating them after changes.

182evaluation report

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

183Gantt chart

A project management tool that shows tasks and their timeframes as horizontal bars along a timeline

184milestone

A marked checkpoint in a project plan, such as a finished prototype, showing a major piece of work is complete by its deadline. Used to check progress.

185critical path

The longest chain of dependent tasks in a project. It sets the shortest possible finish time, and any delay to a task on it delays the whole project. Tasks off it have float.

186scope creep

The uncontrolled growth of a project's features beyond the original scope, which adds extra time and cost unless changes are controlled.

187personnel changes

When a team member leaves or is absent, their skills are lost and tasks must be reassigned, which can disrupt task allocation and delay the timeline of a project plan.

188technical issues

Problems like bugs, tool failures or lost files that delay tasks and force changes to a project plan. Contingencies (backups, spare time) reduce their impact.

189project log

A record of each work session: the date, what was done, any problems and the next step. It shows actual progress against the plan and evidences why the plan changed.

190project journal

A dated record of progress, decisions, problems, solutions and reasons for changes, written as development happens and kept as evidence for evaluation.

191actual vs expected duration

Progress is tracked by recording how long each task really took, comparing it with the planned time, and noting any milestone achieved.

192adjusting tasks

Changing a project plan's tasks by adding, removing, reordering or reassigning them when circumstances change, so the plan stays realistic and the project stays on track.

193Adjusting time frames

Changing a task's start date or duration when work takes longer or shorter than planned, then moving any dependent tasks and deadlines to match.

194annotation

A short dated note added to a project plan that explains a change, giving the date and the reason, or describes how far a task has progressed.

195number of changes

A plan that needed few changes was likely more effective. Count the changes made during the project and compare that count with the size of the plan, such as its total tasks.

196Reason for change

The cause of a plan change, classed as scope creep, personnel, technical issues or poor estimates. Patterns in these causes show how effective the original plan was.

197impact of changes

Judging how changes to a project plan affected completion, such as delays, dropped features and quality, and whether the project finished on time.

198Project plan effectiveness judgement

A judgement of how well a plan worked, using evidence from the number, reasons and impact of changes, plus improvements for next time.