Exam practice

• git add: stages changes, choosing which go into the next commit.
• git commit: saves the staged changes as a commit, a snapshot with a message, author and time.
• git log: lists the commits in the history, newest first.
• git diff: shows the lines taken out and put in, between the files and the last commit, or between two commits.
• git branch / git switch -c name: makes a new branch, a separate line of commits (switch -c also moves onto it).
• git merge name: joins another branch’s commits into the branch you are on.
• git push: sends your new commits to the shared remote.
• git pull: brings in other people’s commits from the remote and merges them into yours.

A merge conflict happens when two branches being merged have both changed the same lines of a file (or lines right next to each other), so git can’t tell which version to keep. Git stops, marks both versions in the file between <<<<<<<, ======= and >>>>>>> lines, and asks a person to decide. To resolve it, edit the file to the correct combined version (often keeping both changes), delete the marker lines, run all the tests, then git add the file and git commit to finish the merge.

• Normal: 12 and −5: ordinary readings well inside the range, which must be converted correctly.
• Boundary: −50 and 60: the lowest and highest values allowed, which must be accepted (and, as values just outside the edges, −51 and 61 must be refused).
• Erroneous: 75 (outside the range) and “cold” (not a number): both must be refused with a clear message, without a crash.

Black-box testing chooses tests from the requirements without looking at the code: for example, from the grading table, test 90 (A+), 89 (A), 35 (D), 34 (NG), 0 and 100.
White-box testing chooses tests by reading the code, so that every part of it runs: for example, one test for each of the seven if/elif branches and one for the else, so every return line is reached.
Black-box finds requirements the code forgot; white-box finds code no test reaches.

• A breakpoint is a line where the program pauses, before the line runs, every time it gets there.
• Step into runs one line, going into any function it calls.
• Step over runs one line, including any function it calls, and stops at the next line.
• Step out runs to the end of the current function and stops where it was called.

A debugger is quicker when you don’t know where the problem is, or need to watch many variables change: you can pause anywhere, look at every value, and move on, without editing the code and taking the prints out afterwards. For a short function where the mistake can be seen by reading, reading is quicker.

Checklist (any four): it meets every requirement, including boundaries and erroneous input; it has tests, and all tests pass; names are clear and comments say why; inputs are checked and there are no secrets in the code; it works for every user (cheap phones, Nepali, screen readers) and keeps only the data it needs; borrowed code, libraries and AI help are credited.
A useful comment: “Line 12: average() divides by len(marks), which is 0 for a student with no marks yet, so the report crashes. Could it return 0.0, or skip the student? A test with an empty list would catch this.” It says where, what goes wrong, why, and suggests a fix.

A pure function gives back an answer that depends only on its arguments, and has no side effects: it changes nothing outside itself, and prints or saves nothing.

• It is easy to test: call it with inputs and compare the result; there is nothing to set up first and nothing to undo afterwards, and the same test always gives the same result.
• It is safe to share and to run at the same time as other code: it can’t change data another part depends on, so it can’t cause the shared-data bugs (race conditions, a list changed under someone) that side effects cause.

• i.cheap = list(map(lambda p: p * 1.13, filter(lambda p: p < 500, prices)))
• ii.cheap = [p * 1.13 for p in prices if p < 500]

It keeps the prices under 500 (120, 450, 80) and adds 13% VAT to each:

prices = [120, 450, 80, 900]print(list(map(lambda p: p * 1.13, filter(lambda p: p < 500, prices))))print([round(p * 1.13, 2) for p in prices if p < 500])

[135.6, 508.49999999999994, 90.39999999999999][135.6, 508.5, 90.4]

(The long decimals are floating point, Grade 11; rounding the results to 2 places, as the second line does, is how a bill would show them.)

(("hajurbuwa", "?a", "?c"), [("parent", "?f", "?c"), ("male", "?f"), ("parent", "?a", "?f"), ("male", "?a")]),
For Aarati: her father is Ram (a parent of Aarati who is male), and Ram’s father is Hari (a parent of Ram who is male), so ask("hajurbuwa", "?who", "Aarati") gives ['Hari']. (In Nepali, a mother’s father is often called hajurbuwa too; a rule for him would use the mother instead.)

• Observer: an object keeps a list of subscribers and tells them all when something happens, without knowing who they are. Example: a chat app tells the message list, the notification and the unread counter when a message arrives; a web page button with addEventListener.
• Strategy: one step that can be done several ways is passed in as a function or object, so the rest stays the same. Example: a map app’s route scoring (fastest, shortest, no tolls); sorting with a key.
• Facade: one simple function or class in front of many complicated parts. Example: a “Pay” button that hides checking the balance, the payment network, the receipt and the SMS; Python’s turtle module.

1. Write (or reread) the requirements, before judging the code.
2. Test it with normal, boundary and erroneous data turned from the requirements; fix every failure.
3. Read every line and review it with the team’s checklist (and have a teammate review it too); she must be able to explain every line.
4. Check that every library or function it uses really exists, is current, and comes from its real publisher.
5. Check it doesn’t copy someone else’s licensed code without following the license.
6. Record the AI use in the commit message (“First draft by an AI chatbot; tested and corrected by Sabina”) and in the README’s credits, following any rules of the school or exam.

Extreme programming is an agile method that adds strict practices: tests written first, pair programming, tiny releases, continuous integration and the customer working with the team. The spiral model goes round in growing rounds, each starting by finding and reducing the biggest risks (often with a prototype), suiting big projects with serious unknowns.

• Direct: stop paper one day, use the computer the next. Quick and cheap, but nothing to fall back on.
• Parallel: keep paper and the computer both for a while, comparing. Safest, but double work for busy staff.
• Phased: one part at a time, such as appointments first, then patient records, then the pharmacy.
• Pilot: one ward uses the whole system first, then the rest.

Recommendation: a pilot in one ward, with paper kept in parallel there for the first weeks. Patients could be harmed by lost or wrong records, so a direct changeover is too risky; full parallel running in every ward would overload the staff; a pilot finds the problems on a small scale, and the pilot ward’s staff can then help train the others. (Other answers earn marks with good reasons.)

• Corrective: fixing a fault found in use. Example: the sibling discount was being given twice; it is fixed.
• Adaptive: changing the program because something outside it changed. Example: the government changes the rules for fee receipts, or a new operating system stops the printer working, so the program is updated.
• Perfective: improving a working program. Example: the office asks for receipts by SMS, or receipts are made ten times faster.

A: weeks 1–2; B: weeks 3–4; C: weeks 5–8; D: weeks 5–6; E: week 9 (it must wait for C, the later of C and D).
The critical path is A → B → C → E: 2 + 2 + 4 + 1 = 9 weeks.
D has float: it ends in week 6 but E doesn’t start until week 9, so D can start up to 2 weeks late (weeks 7–8) without delaying the project.
A Gantt chart shows one row for each task with a bar over those weeks, milestones (such as “design agreed” at the end of week 4 and “handover” at the end of week 9), and the critical tasks marked.