Exam practice

• A real user who will meet you often: one person or small group, with the problem now, who will try each version. Fails: “an app for all students in Nepal”: nobody to watch at work.
• A real problem, not a solution: something you have seen the user struggle with. Fails: “a blockchain for our school”: a technology looking for a use.
• Substantial: needs a team and the course (stored data, more than one kind of user, rules to test). Fails: a page that converts meters to feet.
• Finishable in a term: its essential part working and tested in the user’s hands before the end. Fails: “a social network for the district”.
• Safe, legal and kind: no data the team can’t protect, nothing students may not run, not a copy of a big company’s service, a plan for afterwards. Fails: an app storing patients’ illnesses, or taking payments.

A good answer cuts it to one user and one problem. For example: the 20 vegetable farmers who sell through one cooperative’s collection center, and its manager, who now phones the city market each morning and writes the prices on a board. Keep: the day’s prices for the vegetables that center sells, entered by the manager each morning, seen on the farmers’ phones (and the board). Cut, into the won’t list: weather (other services do it; no data of our own), crop diseases (a wrong answer could cost a crop; Unit 6’s risks), government schemes (they change; the team can’t keep them right), every language (start with the language the farmers use, Nepali, and maybe one more they ask for).
The reasons: a real user who can be met (test 1), a problem seen (test 2), still substantial (daily data, two kinds of user, a history to keep, tests of the prices’ ranges; test 3), finishable (test 4), and no personal data needed (test 5).

For example:

• i.The librarian can lend a book (find the student, scan or type the number on the book, save) in under 30 seconds, on the library’s computer. Checked by timing ten loans at the acceptance test.
• ii.Every screen can be used with a keyboard alone and is read correctly by a screen reader, and works with the text twice as big. Checked on each screen with the screen reader on.
• iii.At the end-of-term stock check, every book is either on the shelf or shown by the app as lent to a named student. Checked by comparing the shelves with the app’s list.

• i.3 × 4 × 10 = 120 team-hours.
• ii.45 + 50 + 40 = 135 hours, more than 120: no. They are 15 hours over even if every estimate is right.
• iii.With every task a quarter longer: the fixed work and the musts take (45 + 50) × 1.25 = 118.75 hours, which just fits in 120, with 1.25 hours to spare. So they can safely plan only the musts, and should keep the shoulds in order of importance, to build only if time is left. (A team this close should also look for a must that can be made smaller, to leave real time to spare.)

A definition of done is the list, agreed by the team at the start, that every piece of work must pass before it counts as finished.
For example:

1. It does everything its issue’s “Done when” lists, including the boundary cases (a fee paid in two parts, a zero balance).
2. It has automated tests, and all the tests pass in the automatic checks.
3. A teammate has reviewed it with the checklist and every comment is answered.
4. It prints a correct receipt on the office’s own printer, in Nepali and English.
5. It stores no more personal data than the receipt needs, and nothing secret in the code.
6. The user guide is updated if what the accountant sees changed.
7. Any library, borrowed code or AI help is in the credits.

Semantic versioning numbers a release major.minor.patch: the patch goes up for bug fixes only, the minor for new features that keep everything that worked before working the same way (the patch going back to 0), and the major for a change that breaks what worked before (the minor and patch going back to 0). Versions starting 0. are for the first building; 1.0.0 is the first its users can rely on.

• i.0.9.5
• ii.1.0.0
• iii.1.1.0
• iv.2.0.0

Because the hardest surprises are where the parts of a system meet, and the skeleton joins them all, running where the product will really be used, at the start of the project, when there is time to deal with what goes wrong. After that, every feature is added to something that already works end to end.
Problems it could find early, for example: the staff’s phones can’t reach the laptop over the health post’s Wi-Fi; the server doesn’t start again by itself after a power cut; Nepali text shows as boxes on an old phone; the laptop is too old for the version of Python the team planned; the health post’s internet is too slow for a server online, so it must run locally.

A good answer has all four parts. For example: “We can’t add patients’ names and numbers. They are health information, which must be protected in ways we can’t promise as a student team, and the Privacy Act, 2075 asks for consent and care with personal information. We agreed in the specification that the app would never hold patient data, and we all signed it. Can you tell us more about the follow-ups: what goes wrong now? If patients forget to come back, that is a real problem; it could be a project of its own, done by people who can protect the data, and we will write it in our handover notes. For now, the follow-up list can stay in your register, where the names already are.”
Why: it gives the reason plainly, points to the agreement, asks about the problem behind the request, and offers another way, so the user’s need is taken seriously without putting patients at risk.

A decision record is a short document, written when a decision is made, giving the date, the decision, the options there were, the reasons for the choice, and what it costs, so that later developers know why the product is the way it is.
For example:

2. The app runs on the library’s own computer. Date: Kartik 4, 2083. Decided by the team and the librarian.
Decision: the app and its database run on the library’s desktop computer; it is used in the library only.
Options: (a) a server on the internet, used from anywhere; (b) the library’s computer.
Why (b): the library’s internet often fails during the day; the school can’t pay for hosting each year; nobody would look after an online server after we leave; the librarian is the only user; and student records stay in the building.
What it costs: students can’t check from home whether a book is in; if the computer fails, the app is down until it is restored from the weekly backup (on the librarian’s pen drive).

Next: watch how a long order is entered, to see where the time goes (perhaps each item needs too many taps; a “same again” button or a quantity box may help), and add a test with a six-item order; find out why the day’s total is slow (perhaps it reads every order ever made rather than today’s) and fix it, then measure again on the owner’s phone. The evaluation should report the slow cases, not only the average, and say the SUS comes from one user only.

A commit count measures how often someone saved code, not what they contributed. One commit can be a day’s careful work or a one-letter fix; someone who commits often isn’t doing more. And much of the most important work in a capstone isn’t commits at all: Asmita, the user lead, may have spent her hours with the user, writing the specification and the success criteria, deciding with the team what to cut, and reviewing others’ code.
Instead, each member should say what they owned and did, with evidence anyone can check: the issues they closed, the reviews they wrote, the documents and decisions they led, the user meetings they ran; and each writes a reflection in their own words.

For example, any three of:

• Requirements, agreed and measured, before building: building started while key requirements, such as how many people would use the site, were unknown. Success criteria with numbers (users at once, time to sign up) would have set targets to build and test against.
• Release in stages: it opened to the whole country on one day. An alpha and beta with a few users, or a pilot in a few places, would have found the problems while few people were affected.
• Test against the criteria before release: it was launched without checking that it met its performance requirements. A release checklist that requires the load tests to pass would have shown it wasn’t ready.
• Believe the review: the readiness review was moved to weeks before launch. Reviews early and at every stage leave time to act on what they find, including moving the date or cutting scope (MoSCoW) instead of releasing something broken.

Answers will differ. A good answer names one real person or small group; describes a problem the student can observe (not an app idea); has musts without which the product fails, and won’ts that keep it safe and finishable (often personal data, payments, more places or users); success criteria with who, what, how much and how checked; and a risk with a concrete action now, not only a worry. For example: User: the treasurer of our tole’s youth club, who keeps members’ monthly savings in a notebook. Problem to watch: how she adds up who has paid at the monthly meeting. Musts: record each payment; each member’s total; a list of who hasn’t paid this month. Won’ts: loans and interest; online payments. Criteria: she records a meeting’s 30 payments in under 10 minutes; the app’s totals match her notebook for three months. Biggest risk: her phone is old and may not run it; check on her phone in week 1 with a walking skeleton.