1.2.3 Software Development

Easy way to remember it

“Input → Loop → Subtract → Add → Repeat → Output”

• INP + STA → store the two numbers

• BRZ → escape the loop when counter hits 0

• SUB ONE → count down NUMB

• ADD NUMA → repeated addition for multiplication

• BRA LOOP → keep looping

• OUT → print the answer

• DAT values at the end (ONE must be 1)

INP // Input first number

STA NUMA

INP // Input second number

STA NUMB

LOOP LDA NUMB // Load counter

BRZ END // If NUMB = 0, end loop

SUB ONE // NUMB = NUMB - 1

STA NUMB

LDA ANSWER // Load current answer

ADD NUMA // Add first number

STA ANSWER // Store new answer

BRA LOOP // Repeat loop

END LDA ANSWER // Load final answer

OUT // Output result

HLT // Stop program

ANSWER DAT 0

ONE DAT 1

NUMA DAT 0

NUMB DAT 0

A simple way to remember this is:

Start at the HEAD → keep going until NULL → compare DATA → move using POINTER → if never found, return -1

Memory Trick: H-D-P--1

Think:

• H → start at HeadPointer

• D → compare the Data

• P → follow the Pointer

• -1 → return -1 if not found

That sequence matches every marking point exactly.

function findNode(toFind, headPointer, linkedList)

    currentNode = headPointer

    while(currentNode != NULL)

        if linkedList[currentNode].data == toFind then

            return currentNode

        else

            currentNode = linkedList[currentNode].pointer

        endif

    endwhile

    return -1

endfunction

(a)

doCheck(3178)

Digits added:
3 + 1 + 7 + 8 = 19

19 MOD 10 = 9

Returned value = 9

(b) Full-marks pseudocode

num = input("enter a number")
value = doCheck(num)

txtfile = openWrite("storedvalues.txt")

txtfile.writeLine(num)
txtfile.writeLine(value)

txtfile.close()

It includes all 5 marking points:

• ✔ input and store/use a value from user

• ✔ call doCheck with the user value as parameter

• ✔ save/use returned value

• ✔ open and close text file correctly

• ✔ write BOTH values to the file

(i) Stack states

Remember: a stack = Last In, First Out (LIFO).

• Input 8 → push 8

• Input 7 → push 7 on top

• Input A → pop 7 and 8, add them → 15, push 15

• Input 6 → push 6 on top of 15

So the stacks are:

• After 7 → 8, 7 Put 8 in bottom box, 7 in box above

• After A → 15 Put 15 in the bottom box only

• After 6 → 15, 6 Put 15 in bottom box, 6 in box above

A quick memory phrase:

“A eats two, adds one back.”

---

(ii) Outputs

1. 9 3 A E

• Push 9

• Push 3

• A → 9 + 3 = 12

• E outputs 12

✅ Output: 12

---

2. 10 5 A 8 S E

For subtraction:

“Second minus first popped.”

• Push 10

• Push 5

• A → 15

• Push 8

• S → 15 − 8 = 7

• E outputs 7

✅ Output: 7

---

3. 25 5 S 2 3 A S E

• Push 25

• Push 5

• S → 25 − 5 = 20

• Push 2

• Push 3

• A → 2 + 3 = 5

• S → 20 − 5 = 15

• E outputs 15

✅ Output: 15

---

(iii) Full-mark explanation

Model full-mark answer:

The S instruction pops the two values 4 and 2 from the stack and pushes back the result 2.
When A is reached, it tries to pop two values, but only one value is in the stack.
This causes a stack underflow because there are not enough values in the stack for the addition operation.

i) State why performance modelling is used to test a system.
Performance modelling is used to simulate how the system behaves under load before it is actually used, especially when testing the real system would be too expensive, unsafe, or time-critical.

ii) Describe how performance modelling can be used in the delivery system.
In the parcel delivery network, performance modelling can test the system using small and very large numbers of deliveries/routes to see how efficiently it performs. For example, it could simulate the largest number of deliveries or possible routes at once and measure whether the system can still calculate routes quickly. This helps developers see how well the system scales as usage increases.

An array can implement a queue by using two pointers: a head pointer and a tail pointer.

• The head pointer stores the position of the item at the front of the queue.

• The tail pointer stores the position where the next item will be added.

• When an item is enqueued, the item is inserted at the tail position and the tail pointer increments.

• When an item is dequeued, the item at the head position is removed and the head pointer increments.

Object-oriented programming (OOP) and procedural programming can both be used to create and manipulate queue data structures, but they do so in different ways.

In OOP, a queue is created as a class. The class contains both the attributes (data) and the methods (operations) that act on the queue. For example, the attributes could include the array storing the items, the front pointer, rear pointer and size of the queue. The methods could include enqueue(), dequeue(), isFull() and isEmpty(). This means the queue is treated as an independent object.

A key feature of OOP is encapsulation. The attributes of the queue can be made private so they cannot be changed accidentally by other parts of the program. The queue can only be manipulated through methods such as enqueue() and dequeue(), reducing the risk of errors and protecting the integrity of the data structure.

Another feature of OOP is that many instances of the queue class can be created. For example:

• CustomerQueue

• PrintQueue

• MusicQueue

Each object has its own data but shares the same methods defined in the class. This avoids rewriting code multiple times.

In procedural programming, the program is organised into a sequence of procedures or subroutines executed in the order they are written. The queue is usually stored in separate variables or arrays, and procedures such as enqueue(queue) and dequeue(queue) must be written to manipulate it.

Unlike OOP, procedural programming does not combine the data and operations together into one object. The queue data often needs to be passed into and returned from procedures each time they are called. If several queues are required, each queue may need separate declarations and the procedures must work with each individual queue separately.

OOP is generally more beneficial than procedural programming when creating several queue structures. A single queue class can be written once and then reused to create multiple queue objects. This reduces duplicated code, improves maintainability and makes programs easier to expand. In procedural programming, creating many queues could require repeated code and extra parameters being passed between subroutines.

OOP can also reduce mistakes because all queue operations are self-contained within the class. Since the attributes can be private, accidental changes from elsewhere in the program are prevented. In procedural programming, global variables may be needed so procedures can access the queue, increasing the chance of unintended side effects and making debugging harder.

In addition, OOP supports features such as inheritance and polymorphism, which can allow specialised queues to be created from a general queue class, for example a circular queue or priority queue, while still reusing existing methods. Procedural programming has less flexibility for extending queue structures in this way.

Overall, procedural programming is simpler and suitable for small programs, but OOP is usually better for creating and manipulating multiple queues because it provides encapsulation, reusable classes, reduced duplication and easier maintenance.

For a complex computer program, both the spiral model and the waterfall model could be used, but they approach development in very different ways.

The waterfall model follows a strict sequence of stages such as requirements analysis, design, development, testing and maintenance. Each stage must be completed before the next begins. For example, the programmer would first gather all client requirements for the complex system, then fully design the program architecture, code the entire system, test it and finally release it.

A major benefit of waterfall for a complex project is that it is highly structured and easy to manage. Large development teams can clearly understand their responsibilities because every stage is documented and planned in advance. It also works well when the client already knows exactly what they want and the outcomes are unlikely to change. Since testing happens after development, the final system can be thoroughly checked against the original specification.

However, waterfall also has drawbacks for a complex program. Complex systems often change during development as clients realise new requirements or problems appear. In waterfall, going back to earlier stages is difficult and expensive because the process is linear. If an error is made in the requirements stage, it may not be discovered until testing, wasting significant time and money. The client also does not usually see a working product until late in development, so feedback is limited.

In contrast, the spiral model is iterative and risk-focused. Development happens in repeated cycles or “spirals”. Each cycle includes planning, risk analysis, development of a prototype and client evaluation. The programmer would first create a small prototype of part of the complex program, gain feedback from the client, improve the design and then repeat the process with additional features added each cycle.

A key advantage of the spiral model for a complex program is that it handles changing requirements well. Since the client gives feedback throughout development, the software can evolve to meet their needs more accurately. Producing prototypes also allows problems to be identified early before the full system is completed. This makes spiral particularly effective for large, high-risk projects where requirements may not be fully understood at the beginning. The strong focus on risk management means dangerous or expensive features can be modified or removed before too much development time is wasted.

The spiral model does have disadvantages. It can take longer and cost more because repeated testing, prototyping and client meetings are required. It also depends heavily on continuous client involvement; if the client is unavailable or indecisive, development may stall. In addition, the process can become difficult to manage for smaller teams because each cycle requires careful planning and review.

Overall, for a complex computer program, the spiral model is usually more suitable because complex systems often involve changing requirements, significant risks and the need for regular client feedback. The waterfall model may still be appropriate if the requirements are completely understood from the start and the project needs a clear, structured development process.

The function starts with:

total = x + y

Then, while x >= 10:

• subtract 10 from both x and y

• add the new x + y to total

---

i.print(mystery(10,20))

Start:

• total = 10 + 20 = 30

Loop runs once (x = 10):

• x = 0

• y = 10

• total = 30 + 0 + 10 = 40

✅ Answer: 40

---

ii.print(mystery(0,70))

Start:

• total = 0 + 70 = 70

Loop does not run because x < 10.

✅ Answer: 70

---

iii.print(mystery(45,55))

Start:

total = 45 + 55 = 100

For mystery(45,55), go through the loop slowly step by step.

The function is:

total = x + y

while x >= 10
    x = x - 10
    y = y - 10
    total = total + x + y

Step 1 — Starting values

x = 45
y = 55

First line:

total = x + y = 45 + 55 = 100

So now:

total = 100

The loop

The loop repeats while x >= 10.

Since 45 >= 10, we enter the loop.

Loop 1

Subtract 10 from both:

x = 35
y = 45

Add these to total:

total = 100 + 35 + 45
       = 180

Loop 2

x = 35, still ≥ 10.

Subtract 10 again:

x = 25
y = 35

Update total:

total = 180 + 25 + 35
       = 240

Loop 3

x = 15
y = 25

Update total:

total = 240 + 15 + 25
       = 280

Loop 4

x = 5
y = 15

Update total:

total = 280 + 5 + 15
       = 300

Now x = 5.

Since 5 < 10, the loop stops.

Final answer

300

✅ Answer: 300

(a) Describe how George can use iteration when reading from the text file [2]

• Use a loop/iteration to repeatedly read each line in Sales.txt.

• The loop continues until the end of the file is reached, processing one sales value each time.

(b) Procedure: salesAnalysis [7]

procedure salesAnalysis()

    dayCount = 0
    salesTotal = 0

    openRead("Sales.txt")

    while NOT endOfFile("Sales.txt")

        dailySale = float(readLine("Sales.txt"))

        salesTotal = salesTotal + dailySale
        dayCount = dayCount + 1

    endwhile

    dailyAverage = salesTotal / dayCount

    print("Number of days: ", dayCount)
    print("Total sales: £", salesTotal)
    print("Average daily sales: £", dailyAverage)

    close("Sales.txt")

endprocedure

The procedure salesAnalysis is used to analyse sales data stored in Sales.txt. First, the variables dayCount and salesTotal are initialised to 0 so the program can keep track of the number of days and the total sales amount. The file is then opened using OPENREAD. A WHILE NOT EOF loop is used to repeatedly read each line of the file until the end of the file is reached. Each line is read using READLINE and converted from a string into a REAL data type so calculations can be performed. During each iteration, the current sales value is added to salesTotal and dayCount is increased by 1. After all lines have been processed, the average daily sales are calculated by dividing salesTotal by dayCount. Finally, the program outputs the number of days, the total sales, and the average daily sales before closing the file.

(c) Explain what data type the values should be converted to. [2]

The values should be converted to a float/real/decimal data type because:

• the sales figures contain decimal places

• the values will be used in calculations such as totals and averages

• they represent monetary values which require decimals

(i) Meanings of the terms

Object – an instance created from a class.

Method – an action/function/procedure that an object can perform.

Attribute – a variable/value stored in an object.

---

(ii) Fully encapsulated Worker class

class Worker

    private name
    private attendance

    public function getName()
        return name
    end function

    public function getAttendance()
        return attendance
    end function

    public procedure setName(newName)
        name = newName
    end procedure

    public procedure setAttendance(newAttendance)

        if newAttendance >= 0 AND newAttendance <= 100 then
            attendance = newAttendance
        end if

    end procedure

end class

1. Inputs two numbers.

2. Subtracts the second number from the first repeatedly (looping) until the remainder is negative.

3. Counts how many times the subtraction was possible → this is the quotient.

4. The last positive remainder is the remainder.

5. Prints the remainder first, then the quotient.

Here’s a clean, full-mark pseudocode version:

START
    // Step 1: Input two numbers
    INPUT num1       // First number (dividend)
    INPUT num2       // Second number (divisor)
    
    // Step 2: Initialize quotient counter
    quotient = 0
    remainder = num1

    // Step 3: Repeated subtraction loop
    WHILE remainder ≥ num2 DO
        remainder = remainder - num2
        quotient = quotient + 1
    END WHILE

    // Step 4: Output remainder and quotient
    OUTPUT remainder
    OUTPUT quotient

END

11(a)

function bookingfee(numtickets, country) {

    var nonUKprice = 4.99;

    var perTicketPrice = 2.99;

    var total = 0;

    if (country != "UK") {

        total = total + nonUKprice;

    }

    total = total + (numtickets * perTicketPrice);

    return total;

}

11(b)(i)

Server-side processing is used because:

• processing is done away from the user’s control/client side processing could be altered

• browser may not support client-side language/scripting could be turned off

• booking fee calculation needs to be correct for all locations

One advantage of client-side processing for the customer is that the website responds much faster because the data is processed on the user’s device instead of being constantly sent to the server and waiting for a reply. This means customers can choose and buy tickets more quickly with less delay.

Or

One advantage of client-side processing for the company is that it reduces the amount of work the server has to do because some processing is handled on the customer’s device. This means the company needs less processing power and bandwidth, which can reduce running costs.

This function is performing a binary search.
A quick way to remember it:

“Check the middle, then throw away half the list each time.”

Step-by-step trace

Initial call:

thisFunction(theArray, 0, 7, 35)

The midpoint is calculated using:

result=num1+((num2−num1) DIV 2)result=num1+((num2−num1) DIV 2)

result=num1+((num2−num1)DIV⁡2)result=num1+((num2−num1)DIV2)

---

Trace Table

Function call	num1	num2	num3	result
thisFunction(theArray,0,7,35)	0	7	35	3
thisFunction(theArray,4,7,35)	4	7	35	5
thisFunction(theArray,6,7,35)	6	7	35	6

Why these values happen1st call

result = 0 + ((7 - 0) DIV 2)
       = 0 + (7 DIV 2)
       = 3

theArray[3] = 20

Since 20 < 35, search the right half:

thisFunction(theArray, 4, 7, 35)

2nd call

result = 4 + ((7 - 4) DIV 2)
       = 4 + (3 DIV 2)
       = 5

theArray[5] = 30

Since 30 < 35, search the right half again:

thisFunction(theArray, 6, 7, 35)

3rd call

result = 6 + ((7 - 6) DIV 2)
       = 6 + (1 DIV 2)
       = 6

theArray[6] = 35

Value found, so the function:

returns 6

Final return value

6

(b)

Binary search

1. Recursion uses more memory because each function call stores new variables on the call stack, and recursive solutions can run out of memory/stack space.
   Iteration uses less memory because loops reuse the same variables and do not continually build up stack space.

2. Recursion involves a function calling itself, which can make code shorter, cleaner, and more elegant/in fewer lines of code.
   Iteration uses loops such as for and while instead of self-calling functions, but may require more lines of code and can sometimes be harder to understand.

function thisFunction(theArray, num1, num2, num3)

    while num1 <= num2

        result = num1 + ((num2 - num1) DIV 2)

        if theArray[result] < num3 then
            // Search upper half
            num1 = result + 1

        elseif theArray[result] > num3 then
            // Search lower half
            num2 = result - 1

        else
            // Value found
            return result
        endif

    endwhile

    // Value not found
    return -1

endfunction

Easy way to remember it

Think of binary search as:

• Check the middle

• Too small? Move left boundary up

• Too big? Move right boundary down

• Found? Return position

• No range left? Return -1

i) Programming construct not used

✅ Iteration

Why?

• The code runs in a sequence.

• It uses selection with BRP jump.

• There is no loop, so no iteration.

ii) Value stored in Z when input is 7

The program checks whether X >= 5.

Input:

• X = 7

• Y = 5

Since 7 - 5 is positive, the branch happens and:

• Z = Y

• therefore Z = 5

✅ Answer: 5

iii) Procedural language equivalent (full-mark version)

X = input()
Y = 5
Z = 0

if X >= Y then
    Z = Y
else
    Z = X
endif

Easy way to remember it

Think of it as:

“Store the smaller value between X and 5 into Z.”

• If X is bigger than or equal to 5 → store 5

• Otherwise → store X

So:

• X = 7 → Z = 5

• X = 3 → Z = 3

OCR Car Park could collect entry and exit times using several different methods. One method is Automatic Number Plate Recognition (ANPR) cameras. Cameras record the registration plate of a vehicle as it enters and leaves, and OCR software converts the image into text with a timestamp. This is fast, automatic and usually more accurate than humans, allowing charges to be calculated instantly. It also reduces staffing costs and can produce reliable statistics about busy periods. However, ANPR systems are expensive to install and maintain, and poor weather or dirty number plates may cause recognition errors. If connected to the internet, the system could also be vulnerable to hacking.

Another method is a ticket or token barrier system. Drivers receive a ticket when entering the car park, and the ticket contains the entry time. When leaving, the driver inserts the ticket into a machine which calculates the cost based on the length of stay. This system is relatively simple and familiar to customers. However, tickets can be lost or damaged, and printers or barriers may fail, causing delays and queues.

A third method would be to use sensors such as pressure pads or infrared sensors at entry and exit points. These detect when a vehicle passes and automatically record times. Sensors are efficient and require little human involvement, but they may incorrectly detect vehicles or fail if hardware becomes damaged.

The car park could also use staff to manually record vehicle entry and exit times. This has the advantage of human judgement and lower setup costs, but it is slow, expensive in the long term because wages must be paid, and is prone to human error such as incorrect times being entered.

There are also important ethical implications. Many drivers may feel uncomfortable being monitored by cameras because their movements are being tracked. ANPR and photography systems may capture faces or vehicle details, which some people see as an invasion of privacy. Automated systems could also reduce the number of staff needed, potentially leading to job losses in the local area.

There are significant legal implications too. Any stored registration numbers, photographs or videos are personal data, so the company must follow data protection laws such as the UK GDPR and the Data Protection Act. The car park must:

• Tell drivers that data is being collected using warning signs.

• Keep data secure to prevent hacking or unauthorised access.

• Only store relevant data for a limited amount of time.

• Ensure the data is accurate and not misused.

In conclusion, ANPR is likely to be the most effective method because it is automatic, accurate and efficient, although it raises the greatest privacy and security concerns. A ticket system is cheaper and simpler, but less convenient and more vulnerable to lost tickets and delays.

The two methodologies being considered are the waterfall lifecycle and extreme programming (XP). Both could be used to develop the new version of De-Duplicator, but they approach software development in very different ways.

The waterfall lifecycle is a linear and sequential methodology. Each phase is completed before moving onto the next stage, for example: requirements analysis, design, development, testing and maintenance. In waterfall, the requirements are normally agreed at the beginning of the project and are expected to remain mostly fixed. This means the software team would carefully define how the duplicate image detection should work before any coding begins.

One advantage of waterfall for De-Duplicator is that the company already has an existing product. Because the original software already detects duplicate files, the requirements for adding image detection may be reasonably clear and stable. Waterfall would allow detailed planning of algorithms, storage methods and image comparison procedures before development starts. Documentation is also strong in waterfall, which would help future maintenance and updates.

However, waterfall can be inflexible. Detecting duplicate images is much more complex than detecting identical files because the team may need to experiment with abstraction methods, image hashing or pattern recognition techniques. If requirements change during development, waterfall makes it difficult and expensive to return to earlier stages. For example, if users later decide they want the software to recognise resized or compressed duplicates, significant redesign may be required.

Extreme programming (XP) is an agile and iterative methodology. Development happens in small cycles with constant feedback from users and regular testing. XP focuses on adaptability and producing working software quickly. Customers or end users are heavily involved throughout the project.

XP would suit De-Duplicator because image detection is likely to require experimentation and refinement. The team could release small prototypes, test them with users and improve the software after each iteration. If customers request new features, such as recognising edited versions of the same image, XP allows these requirements to be added during development.

Another major strength of XP is code quality. XP uses practices such as pair programming, continuous testing and frequent reviews. This is important because image comparison software could become very complex and performance-critical. Pair programming would reduce errors and improve the efficiency of the detection algorithms. Continuous testing would also ensure that adding image detection does not break the original duplicate file finder features.

XP also improves communication because developers collaborate closely and users remain involved throughout. This could help the software team better understand what users actually mean by “duplicate images.” For example, some users may expect identical pixel matches, while others may expect visually similar images to count as duplicates.

Despite these advantages, XP does have weaknesses. It can be harder to predict timescales and costs because requirements can continue to change. It also requires strong teamwork and constant customer involvement. If users are unavailable for feedback, the project may lose direction. In addition, XP may produce less formal documentation than waterfall, which could make future maintenance more difficult.

Overall, I would recommend extreme programming rather than waterfall for this project. Although waterfall provides strong structure and documentation, the development of image detection software is likely to involve changing requirements, experimentation and ongoing refinement. XP is more flexible and better suited to projects where developers may need to repeatedly improve algorithms based on testing and user feedback. The focus on code quality through pair programming and continuous testing is especially important because the success of De-Duplicator depends on producing accurate and efficient image matching software that performs better than competitors. Therefore, XP is the most appropriate methodology for this project.

(i) Stages of the waterfall lifecycle

• Feasibility Study

• Investigation / Requirements Elicitation

• Analysis

• Design

• Implementation / Coding

• Testing

• Installation

• Documentation

• Evaluation

• Maintenance

(ii) Justify why the waterfall lifecycle is suited to developing the operating system

The waterfall lifecycle is suitable because an operating system is a large and complex project, and waterfall works well for large-scale developments where each stage is carefully planned before moving on.

It also suits projects with stable requirements. The core requirements of a mobile phone operating system are unlikely to change significantly during development, so a structured sequential approach is effective.

(iii) One disadvantage of using the waterfall lifecycle

If the requirements change during development, the waterfall model is difficult and expensive to adapt, often causing extra time and cost because earlier stages may need to be repeated.

(i) Describe how black box testing can be used to test a program.

Black box testing checks whether the expected output is produced for different inputs.
The tester does not examine the program code; they only test the program against the specification/requirements.

(ii) Test data

Test data	Test data 1	Test data 2
Normal	25	67
Extreme	1	100
Invalid	0	101

Easy way to remember:

Normal = safely inside the range

Extreme = edges of the range → 1 and 100

Invalid = outside the range or wrong type → 0, 101, "x"

(i) State what is meant by alpha testing.

Alpha testing is testing carried out by the programmer/developer (Beryl) or other employees within the company before release to users.

(ii) Describe how Beryl will use white box testing in her program.

Beryl will use the source code to test all possible paths and condition statements in the program.
She can perform dry runs/trace tables to check that each decision (for example A = 90, x = y) produces the correct output.

(iii) Complete the black box testing table

Test data	Reason for test	Expected outcome
A = 90 x = 100 y = 120	Angle is exactly 90 and the difference between x and y is ≥ 10% of x, so the lengths are not considered equal	RECTANGULAR
A = 90 x = 100 y = 105	Angle is exactly 90 and the difference between x and y is < 10% of x, so the lengths are considered equal	SQUARE

Easy way to remember it

90° + equal lengths = SQUARE

90° + unequal lengths = RECTANGULAR

White box = look inside the code

Alpha testing = done by the developers/programmers

Start with the pseudocode:

d = 5

if ((a > b) OR (b >= c)) then
    if ((c < a) XOR (c < b)) then
        d = 15
    else
        d = 16
    endif
else
    d = 14
endif

A quick memory trick for XOR:

XOR = “Exactly ONE is true.”
(Not zero, not two.)

(a) a = 42, b = 41, c = 42

First condition:

• 42>41 = TRUE

• 41≥42 = FALSE

TRUE OR FALSE = TRUE → continue inside.

Second condition:

• 42<42 = FALSE

• 42<41 = FALSE

FALSE XOR FALSE = FALSE

So the else runs:

d = 16

✅ Answer: 16

---

(b) a = 42, b = 36, c = 4

First condition:

• 42>36 = TRUE

• 36≥4 = TRUE

TRUE OR TRUE = TRUE

Second condition:

• 4<42 = TRUE

• 4<36 = TRUE

TRUE XOR TRUE = FALSE
(because XOR needs exactly one TRUE)

So:

d = 16

✅ Answer: 16

---

(c) a = 42, b = 36, c = 36

First condition:

• 42>36 = TRUE

• 36≥36 = TRUE

TRUE OR TRUE = TRUE

Second condition:

• 36<42 = TRUE

• 36<36 = FALSE

TRUE XOR FALSE = TRUE

So:

d = 15

✅ Answer: 15

---

(d) One possible value of b if a = 42, c = 44 and d = 14

To get d = 14, the first IF must be FALSE.

So:

(a > b) OR (b >= c) = FALSE

For an OR statement to be FALSE, both parts must be FALSE.

Given:

• a=42

• c=44

We need:

• 42>b = FALSE → b≥42

• b≥44 = FALSE → b<44

So:

42 ≤ b < 44

Possible integer values:

• 42

• 43

✅ One valid answer: 42
(43 also works)

A = input("Enter value A")
B = input("Enter value B")

myFile = openWrite("output.txt")

if A < B then
    myFile.writeLine("A is less than B")

elseif B < A then
    myFile.writeLine("B is less than A")

else
    myFile.writeLine("A is equal to B")

endif

myFile.close()

OCR-friendly structure to memorise

Think:

INPUT → OPEN → COMPARE → WRITE → CLOSE

1. Read in A and B

2. Open the file

3. Use if / elseif / else

4. Write the correct message

5. Close the file

Rapid Application Development works in a cycle:

1. A prototype of the word game is quickly created.

2. The prototype is tested/evaluated by users and their feedback is collected.

3. The developers make changes and improvements based on the feedback.

4. This process is repeated again and again until the prototype becomes the final finished product.