The Build Phase at a Glance

How the design becomes the build

Module 1's documents are not left behind in Module 2; every one of them becomes something that runs or something that is tested. The thread from design to build, for the worked project:

When the build shows that a design document was wrong, the document is corrected and given a new version, as the worked UML set was on 25 September (Chapter 35). The code and the documents describe one system for the whole semester, not only until the design review.

The order the worked team built it

The plan of Chapter 17, from the day after the design review:

Unit tests have no task of their own: they are written with the code they test, in B and V, which is where their hours fall. Around the tasks sit five dates that matter as much: the practice deployment on the lab desktop in week 8, 14 to 18 September, answering the one skill nobody had; the first increment review on Thursday 24 September; the guide's code review on Thursday 1 October; the second increment review on Friday 9 October, with the head cook; and the last day of work, Monday 26 October. Friday 2 October is a holiday.

Two increments, each one working

The tasks are grouped into the two increments of Chapter 15, and each ends in something the canteen can use:

The first increment needed a signed-in student before anyone could order, so signing in came with it, using the accounts the setup script creates; registering new accounts waited for the second. FR-10, a Should, came early for the reason Chapter 15 gives: it is checked inside the same transaction as the stock rule.

The hours

Module 2's 120 person-hours, as the WBS shares them (Chapter 16):

Four students at 30 hours each. Notice what is small: deployment is 12 hours, a rehearsal in week 8 included, not a panic in the last weekend; and the documents are 15, because most of the report is Module 1's documents, already written and already corrected.

How to read Module 2 of this book

Module 1 printed documents. Module 2 prints the application itself, and three rules make what it prints trustworthy:

• Every file is the real file. Each listing marked with a file name is checked, character for character, against the worked application's source, so the book cannot show a line the application does not contain.
• Every terminal session was run. Each one was run on Ubuntu 24.04, the system the worked team deploys to, against that exact code, and its output copied from the screen, not typed.
• The application's tests pass. The whole suite runs on three versions of Node.js, 22, 24 and 26, before any session in this book can be run at all.

And the rule from Chapter 2 still holds: copy the method, never the project. Read what the worked team built and why, then build the same kind of thing for your own problem. An examiner who asks for a small change during your demonstration will find out at once whose code it is.

Do this for your project

1. Put your build plan's dates in your plan, with your increment reviews and your guide's code review on fixed dates.
2. Set up every member's machine in the first days, and create the repository on the first day (Chapters 39 and 61).
3. Build in thin slices that each work end to end, Must Haves first, and show each one to your users.
4. Write the tests with the code, not after it.
5. Deploy once early, as a rehearsal, long before it counts.
6. When the build shows a design document is wrong, correct the document and give it a new version.
7. Keep the last two weeks for testing at scale, the report and the presentation.

Mistakes that cost marks

Everything built, then everything tested, in the last week, when nothing can be fixed any more.

The first deployment on the day of the demonstration. It fails for a reason nobody has seen before, in front of the examiner.

One member writing all the code. The repository's history shows exactly who did, and the viva asks the others.

Code and design that drifted apart without anyone noticing, so the report describes a system that was never built.

Documentation written from memory the night before, with screenshots of a version that no longer exists.

Quick revision

• Module 2: Implementation, Testing, Deployment & Evaluation Phase, 30 hours per student.
• Five rows: application development, integration and system testing, deployment (with GitHub, mandatory), performance and security testing, final documentation.
• Four deliverables: working application, GitHub repository, final report, presentation and demonstration.
• Every Module 1 document becomes code or tests; when the build proves one wrong, it gets a new version.
• Build in increments that each work; tests with the code; deploy early as a rehearsal.

Questions you must be able to answer

1. What does MU's Module 2 cover, and what are its deliverables? Application development (frontend and backend implementation, database integration, authentication and validation, error handling), integration and system testing (unit, black-box and integration testing, test case preparation, bug tracking), deployment (cloud deployment or local hosting, an APK build, server configuration where applicable, and GitHub, which is mandatory), performance and security testing, and final documentation. Its deliverables are the working application, the GitHub repository, the final report, and the presentation and demonstration.

2. What does "Cloud deployment / Local hosting" in MU's syllabus mean for a project? That either is acceptable: the application may be put on a cloud server or hosted on a local machine. The worked team hosts its trial locally, on the college lab's desktop, because its constraints require the college's machine and network.

3. How do the Module 1 documents relate to the Module 2 work? Each becomes something built or tested: the pages and wireframes become the frontend, the schema becomes the database, the API specification becomes the routes and their validation, the security design becomes the authentication code and its tests, and the SRS's verification column becomes the test plan. When the build shows a document to be wrong, the document is corrected and versioned.

4. Why did the worked team build in two increments rather than all at once? So that each increment ended in something that worked and could be shown to the canteen: after the first, students could already order and the counter could serve, and the review of it found a change, the counter's list refreshing itself, early enough to make before anything was built on top of it.

5. Why write unit tests during the build rather than after it? Because a test written with the code catches a mistake while the code is fresh and nothing depends on it yet, and because tests written at the end, under time pressure, are the first work to be cut.