MAIE6000C Chap.3 Engineering Foundations and Bounded Change
Engineering Foundations and Bounded Change
The readiness rubric is a work plan in disguise
This module establishes the engineering baseline and launches the individual readiness assessment, and the published framing of that assessment is direct: it concerns being ready and being reproducible, rather than how ambitious a feature is. The rubric bears it out.
Of a hundred points, fifteen go to repository correctness and submission compliance, twenty to environment and project setup readiness, twenty five to functional implementation within scope, fifteen to testing and verification, fifteen to documentation and explanation, and ten to engineering discipline and code quality.
Thirty five points are available before the required task is attempted and thirty depend on work done after it is finished.
Bounded is a property of the finish condition
The course asks you to make bounded changes safely, which is easy to read as make small changes. It is not quite that. A change is bounded when you can say in advance what would count as finishing it, in terms another person could check.
A two-line edit with no such statement is unbounded because nothing stops it growing; a fifty-line edit with one is bounded because the fifty-first line has to justify itself.
The rubric criterion on engineering discipline is reading for this when it asks whether changes appear deliberate rather than ad hoc.
Repository workflow and the three tags
Six steps make up the minimum workflow: pull or clone the correct official repository, create a small named branch when appropriate, commit clearly and regularly, push before deadlines, keep documentation in sync with the implementation, and create the required tag at milestone checkpoints.
Four branch prefixes are recommended and three tag spellings are required exactly.
Seven repository paths are specified: a readme, an architecture document, an operations document, a decision-record folder, and one submission folder for each milestone week.
Two repositories, arriving at different times
You receive a private individual readiness repository in Week 3, provisioned by staff, and your team receives one private project repository once teams are finalised, also provisioned from the starter template.
The instruction is explicit: never set up your own graded repository unless instructed.
Work started elsewhere has to be moved later, and moving code between repositories is exactly the operation that loses history, which the final rubric scores under repository discipline and semester progression.
Three testing layers, each blind to the next
Unit, integration and smoke verification are named, and the starter carries a place for each.
The standard the course sets is worth quoting in shape: you do not need perfect coverage, but you do need credible evidence that important behaviour was checked. Credible is the operative word. A test written after the change, which passed on its first run and has never been observed to fail, has not yet demonstrated that it is connected to the behaviour it claims to check.
Writing the assertion first and watching it fail for the right reason takes a minute and converts a statement into evidence.
The environment is itself a graded artefact
Three version checks come before anything else, covering the version-control client, the container runtime and the multi-container tool.
The course states that you should not install the application framework, the server, the database, the object-relational layer, the migration tool or the test runner separately, because all of those run inside the containers.
The setup order is equally specific, from creating the account through installing tooling and accepting the organisation invitation to a verified run of the starter, and the course warns against discovering a broken environment in Week 3.
What this chapter covers
- 01
The readiness rubric read as a distribution of effort
- 02
What bounded actually constrains, and why the finish condition comes first
- 03
The six-step repository workflow and where documentation fits
- 04
Three milestone tags, four branch prefixes, seven required paths
- 05
Which repositories are provisioned, and when
- 06
Unit, integration and smoke testing by what each cannot see
- 07
Why a test that has never failed is not yet evidence
- 08
The verification commands and the setup order that precede them
One bounded change, from finish condition to submission note
- 3Write the finish condition before touching any file.
- 3List the smallest set of edits that satisfies it.
- 2Say what the submission note records.
Key terms
- Bounded Change
- An edit with a finish condition written in advance, stated so that another person could confirm it was reached without asking what was intended.
- Milestone Tag
- A named repository point that fixes the state a reviewer will inspect, with three exact spellings specified for the three checkpoint weeks.
- Smoke Test
- A check that the whole stack comes up and answers, which catches broken startup and wiring but cannot detect a subtly wrong answer.
- Integration Test
- A check that two or more components agree with each other, which catches contract mismatches invisible to a test of either component alone.
- Decision Record
- A short document capturing why an architectural choice was made, kept in the repository so the reasoning survives into the final brief and the oral defence.
- Submission Note
- The record accompanying a checkpoint, naming what changed and how it was verified, and matching the repository address, tag and commit identifier.
- Clean Checkout
- A fresh copy of the repository with no local files or state carried over, used to expose dependencies that exist only on a developer's own machine.
Engineering Foundations and Bounded Change FAQ
What does the Week 3 readiness lab actually assess?
Six criteria, and only one of them is the code. Repository correctness and submission compliance is worth fifteen, environment and project setup readiness twenty, functional implementation within scope twenty five, testing and verification fifteen, documentation and explanation fifteen, and engineering discipline and code quality ten.
Thirty five points are reachable before you attempt the task at all, and another thirty depend on verification and the written explanation afterwards. The course describes the assessment as being about readiness and reproducibility rather than feature ambition, and the point distribution is the clearest statement of that.
Why does the course insist on branches and tags for a small project?
Because the tag decides what a reviewer reads and the history is itself assessed. The checkpoint rule states that where a milestone asks for a tag, whatever the tag points at is the state under review, so work pushed afterwards is invisible to the mark. Separately the final rubric scores semester progression and repository discipline, looking for clear milestone progression and evidence of iterative development.
A repository containing three large commits reports something about how the team worked regardless of whether the system runs, and that report is part of the assessment.
How much testing is enough for this course?
The stated standard is credible evidence that important behaviour was checked, explicitly not perfect coverage. In practice that means choosing the behaviours whose failure would break the workflow and writing one check for each: an item can be submitted and stored, a job is claimed and completed, a failure leaves a visible state.
The quality marker the rubric looks for is awareness of correctness and regression risk, which you demonstrate by saying what each test protects and what it does not cover, rather than by producing a larger number of tests.
Assessment move
Run one bounded change on the starter before the readiness lab is released, purely as a rehearsal: write the finish condition, make the edit, verify from a clean state and write the two-line note. The exercise takes an hour and it converts thirty five of the rubric's hundred points from things you hope are fine into things you have checked.
Working through Engineering Foundations and Bounded Change in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C Engineering Foundations and Bounded Change question and get a clear, step-by-step explanation grounded in how MAIE6000C is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
