Software Processes & Management, drawn out

What this subject is about

Most software is built as a project. The subject's slides, following the Project Management Body of Knowledge (PMBOK, the standard reference for the profession), define a project as "a temporary endeavour to create a unique product, service or outcome". Building a booking system for a clinic is a project: it starts, it ends, and nobody has built exactly that system before. Running the clinic's help desk afterwards is not a project but operations, ongoing work with no planned end. And the way the team works, for example Scrum, is a process: a repeatable series of steps that can be reused on project after project.

The running example on this site is the Medic case study used in the tutorials. A team builds a training simulator on which surgeons can practise ear surgery (cochlear implants and temporal-bone operations) without needing a cadaver, a donated human body. Its hand controls push back like real tissue, which is called force feedback or haptics. Each Part applies its ideas to Medic, so you see every technique used on the same project.

Projects are hard because they introduce change, cut across departments, and deal with the unknown: nobody can be certain how long new work will take or what will go wrong. Project management is the discipline of steering one anyway. Its oldest picture is the triple constraint, or iron triangle: scope, time and cost (resources) are linked, so a change to one forces a change to another or a loss of quality.

The map below is the whole subject on one page. It appears at the top of every Part, with that Part highlighted, so you always know where you are.

The exam and where the marks are

The final exam is on Wednesday 18 November 2026 at 12:30 pm at the Royal Exhibition Building. It is a Canvas quiz (Canvas is the university's online learning system) taken on your laptop under LockDown Browser, a browser that keeps you inside the exam: 15 minutes of reading time, during which you can't type or select anything, then 2 hours of writing. It is closed book except for two double-sided A4 pages of your own notes, and a non-programmable calculator is allowed. The exam is worth 50% of the subject and has a hurdle: you must score at least half of it to pass, whatever your assignment marks.

The paper has two kinds of question. Multiple-choice questions (MCQs) have exactly one correct option and are worth 2 marks. Multiple-response questions (MRQs) ask you to tick every correct option and are worth 3 marks. The rest of the paper is extended written questions, typed answers that apply ideas to a scenario or work through a calculation.

The staff's official practice exam has the same format as the final, and they posted an answer for every question. Its questions show what each Part has to prepare you for. Don't worry if the terms in this table are new: each one is taught from scratch in the Part listed beside it.

How the topics fit together

PMBOK groups project work into five process groups. Initiating, planning, executing and closing follow one another, while monitoring and controlling runs alongside them all, comparing what is happening with the plan and feeding corrections back. Almost every Part of this subject is a tool for one of those groups, so following a single project from idea to handover shows where each one fits.

Two threads run through the whole subject, and spotting them makes the details easier to remember. The first is plan-driven versus adaptive. Formal, plan-driven processes (Part II) fix the scope and plan everything up front, then schedule with task networks and track with earned value (Part VIII). Agile processes (Part III) work in short repeated cycles called iterations. They fix the time and cost of each iteration and let the scope flex, then estimate in story points and track with burndown charts, which plot the work still left (Part VI). Most topics have a formal version and an agile version, and the exam likes to ask you to compare them or pick one for a case. The second thread is making uncertainty visible early: risk registers (lists of what could go wrong), stakeholder grids, quality reviews and change control (a formal route for approving changes) all exist so that problems surface while they are still cheap to fix.

How to read this site

Each Part opens with what you'll be able to do by the end, and a copy of the map. Sections build on each other, so read a Part in order the first time. Coloured boxes mark the kind of content, so you can skim for what you need later:

Two more kinds of box round this out: example boxes work a concrete case, and an In short box closes each section with its main points.

Step-through diagrams have Back and Next buttons. Use them to watch a calculation fill in one cell at a time, or a process run one stage at a time, with what is happening and why written underneath. "Check yourself" questions hide their answers until you click; try each one honestly before you look. Answers say where they come from: the staff's official practice-exam answers are marked as official, questions from the predecessor subjects' past papers (433-443 and 433-341, as no SWEN90016 paper is public) are marked as such, and the rest are this site's own worked answers.

If a symbol in a diagram puzzles you, the diagram key draws each kind of picture once with every element labelled, and the glossary defines every term with a link to where it is taught.