Appendix
Diagram Key & Glossary
How to read the pictures on this site, and every term the subject uses in one alphabetical list. Each kind of diagram is drawn once here with every symbol labelled, so that when you meet one in a Part you already know its language.
A.1
How the Diagrams Are Drawn
Software project management is a subject about plans, people and processes. Almost every picture in it answers one of a handful of questions. In what order do the phases or activities happen, and where can you go back? When does each task run, and which tasks can't slip? How is the project tracking against its plan? Where does a risk or a stakeholder sit on a grid? Who plays which role, and what artefacts do they work with? This site draws each of those questions in one consistent style, and this section shows each style once with every symbol labelled.
Process flows: phases and hand-offs
A phase or step is a rounded box. A solid arrow with a filled head is a hand-off: the next phase starts from what the previous one produced. A dashed arrow with an open head means going back, either a feedback loop or rework. The waterfall model below is drawn as a cascade, with each phase a step lower than the one before, which is how Royce's 1970 paper drew it.
Gantt charts: when each task runs
A Gantt chart puts time across the page and one task on each row, so the length of a bar is the task's duration. Bars with a red border are on the critical path: if any of them slips, the whole project finishes late. A dashed outline after a bar is slack (also called float), the time that task can slip without delaying the end date. A gold diamond is a milestone, an event with zero duration such as a release. The dashed gold vertical line marks today, the status date.
Activity networks: dependencies and the critical path
An activity-on-node (AON) network draws each task as a box and each dependency as an arrow: an arrow from B to C means C can't start until B finishes. Every node uses the course's layout. The top row holds the early start (ES), the duration and the early finish (EF). The bottom row holds the late start (LS), the slack and the late finish (LF). Critical tasks, the ones with zero slack, have red borders and red arrows. Times are counted from 0, so "ES 5" means "can start once 5 weeks have passed".
Tracking charts: progress against the plan
Charts that track a project put time across the bottom and the quantity being tracked up the side, over a faint grid. A dashed line is always the plan or ideal; a solid line with dots is what actually happened, one dot per measurement. The two charts below are the ones the course uses most: the Scrum burndown chart, and the earned value chart from formal project tracking.
Grids and matrices: placing things in two dimensions
Several tools in the course place items on a two-axis grid, so that their position tells you what to do about them. Cells are tinted by urgency: green low, gold medium and red high. Items on the grid are numbered badges, explained in a list or caption.
People, roles and artefacts
People are drawn as stick figures, coloured by role and kept the same colour across a whole Part. Artefacts, the documents and lists a process produces, are drawn as file icons or as stacks of yellow sticky notes, one note per item. A board is a set of grey columns that items move across from left to right.
Cycles and hierarchies
Iterative processes repeat, so they are drawn as a loop of boxes joined by curved arrows. Breakdowns, such as a work breakdown structure (WBS) or an organisation chart, are drawn as trees with the whole at the top and its parts below, numbered so that 1.2 is the second part of 1.
In short
- Boxes are phases or tasks; solid arrows go forward, dashed arrows go back.
- Red means critical (zero slack) or high risk; gold marks milestones, today and exam material; dashed lines are plans and slack.
- Role colours stay fixed within a Part, and every caption tells you what to notice.
A.2
Glossary
Every key term in the subject, alphabetically, with a one-line definition and a link to the Part that explains it in full.
| Term | Meaning | Part |
|---|---|---|
| # | ||
| 100% rule | A WBS covers all of the project's work, including management, testing and deployment, and the children of each node sum to their parent. | VIII |
| 3 C's | The three parts of a user story: Card (a placeholder), Conversation (details worked out just in time) and Confirmation (acceptance criteria and tests). | VI |
| A | ||
| Absent stakeholder | Someone affected by a decision who has no voice in it, such as patients whose data sits in a test database. | IX |
| Acceptance criteria | Story-specific conditions of satisfaction, written as Given/When/Then, that will be true when the story's functionality is complete. | VI |
| ACS Code of Professional Ethics (2023) | The Australian Computer Society's code, built on four core values (honesty, trustworthiness, respect for others, respect for the profession) with 26 lettered clauses. | IX |
| Active listening | Empathetic listening that shows interest, asks questions, keeps eye contact and reads verbal and nonverbal messages. | V |
| Activity-on-node (AON) | A task network notation in which boxes are tasks and arrows are dependencies; the course's notation. | VIII |
| Actual cost (AC) | The cost actually incurred for the work completed to date (old name ACWP). | VIII |
| Adequacy | Whether an artefact as a whole is fit for its purpose and the next phase: complete, at the right level of detail, consistent, compliant and verifiable. | VII |
| Aggregate CI | A named collection of CIs managed as one unit, such as a module made of code, tests and a diagram. | X |
| Agile | A set of values and principles (the 2001 Agile Manifesto) for building software through frequent feedback; not a single process model. | III |
| Agile Manifesto | The 2001 Snowbird statement of four values, each a preference of one thing over another, backed by twelve principles. | III |
| Agile mindset | A thought process of understanding, collaborating, learning and staying flexible, resting on respect, sustainable flow, innovation and relentless improvement. | III |
| Agile Release Train (ART) | A long-lived virtual organisation of about 5–12 agile teams (50–125 people) that plans, commits and executes together from one Program Backlog. | XI |
| Agile Testing Quadrants | A 2 by 2 grid sorting tests as business- or technology-facing and as supporting the team or critiquing the product (Q1 to Q4). | VII |
| Answer skeleton | The order in which to write an answer to a given question type, such as formula, working, result and meaning for a calculation. | XII |
| Architectural runway | The technical foundation that lets upcoming Features be built without redesign. | XI |
| ATDD | Acceptance test-driven development: agree acceptance criteria with the three amigos, write acceptance tests, then write the code. | VII, XII |
| Audit | An independent check of a sample of objective evidence for conformance to standards; a product audit or a process audit, both QC in this course. | VII |
| Avoid / mitigate / transfer / accept | The four threat strategies: make P or I zero; reduce P or I; shift the burden to another party at a cost; or deliberately do nothing. | IV |
| B | ||
| Backlog refinement (grooming) | Ongoing splitting, detailing, estimating and re-ordering of backlog items; the slides cap it at about 10% of team time. | VI |
| Backward pass | Working right to left to find each task's late finish (the minimum LS of its successors) and late start. | VIII |
| Baseline | An approved, frozen version of the scope, schedule or cost plan that progress is measured against; it changes only through formal change control. | I, V, X |
| Bases of power | French and Raven's legitimate, reward, coercive, expert and referent power; expert and referent are most effective for a PM. | V |
| Basic CI | A single configuration item created by a person, such as a source file or one requirement. | X |
| BDD | Behaviour-driven development: ties stories to business goals with the Five Whys, outside-in thinking and the shared Given-When-Then notation. | VII |
| Benefit hypothesis | The statement of why a Feature is worth building, which can be checked once it is delivered. | XI |
| Branch | An isolated line of development for a change, a variant or maintenance work. | X |
| Brooks' law | Adding manpower to a late software project makes it later, because of training and communication overhead. | VIII |
| Bucket system | Estimation for large backlogs: anchor stories go into point-labelled buckets, members place the rest silently, then anyone can challenge a placement. | VI |
| Burn-up chart | A chart of completed work rising towards a separate scope line, so scope changes show up apart from progress. | VI |
| Burndown chart | A chart of work remaining (y) against time (x), with an ideal line and an actual line, read to see whether a sprint or release is on track. | VI |
| Burst activity | A network activity with two or more immediate successors, where paths split. | XII |
| Business case | The living document, owned by the sponsor and prepared by the PM, that judges whether a project is and remains desirable, viable and achievable. | I |
| Business driver | The problem, pressure or opportunity that makes an organisation willing to invest in a project. | XII |
| Business Owners | Key stakeholders accountable for the ART's business outcomes; they give business context and score PI objectives. | XI |
| C | ||
| Case-study analysis method | Eight steps from goals and setbacks through cause–practice–effect chains to one justified alternative SDLC and its limitations. | XII |
| Change control | The procedure that evaluates, approves and carries out changes affecting more than one CI. | X |
| Change control board (CCB) | The group that approves or rejects changes to a baselined plan through Perform Integrated Change Control. | I, V, X |
| Change request (CR) | A formal, logged request to change something under configuration management. | X |
| CHAOS categories | Standish Group classes: successful (on time, on budget, all features), challenged (delivered but late, over budget or short of features) and failed (cancelled). | I |
| CHAOS category | The Standish Group's project outcome: successful, challenged (late, over budget or cut) or failed. | XII |
| CMM / CMMI | The SEI's five-level maturity model, from 1 Initial through Repeatable, Defined and Managed to 5 Optimising. | VII |
| COCOMO | Boehm's model turning size in KLOC into effort (E = a × KLOC^b) and duration (D = 2.5 × E^c). | VIII |
| Code-and-fix | Ad hoc development: write code and edit it until it seems to meet the requirements, with no requirements, design or test phases. | II |
| Collaborative team | A flat team structure where members decide within their own area of expertise and consult only those with relevant expertise; how Agile teams work. | V |
| Communication channels | The potential lines of communication among n people, n(n−1)/2; adding a person to a team of n adds n channels. | V |
| Communication matrix | A plan of who is told what, in what format, how often and by whom, built from the stakeholder analysis. | V |
| Communication plan | Plan built from the stakeholder analysis with the 5 Ws and 1 H, defining what, which channel, when, who, needs, resources, confidentiality, flow, constraints, templates and escalation. | V |
| Communications charter | A team's collectively agreed, living summary of its communication norms and practices. | V |
| Confidence vote | A fist-of-five vote at the end of PI Planning; if confidence is low, the plan is reworked. | XI |
| Configuration audit | A check that the repository is consistent and changes were made properly, e.g. comparing deployed versions with the baseline. | X |
| Configuration drift | Items gradually moving away from their baseline or from each other without a decision to change them. | X |
| Configuration item (CI) | An artefact that requires configuration management: a document or component tracked and maintained under version control. | X |
| Configuration management (CM) | The process of managing changes to a software system while keeping the integrity and traceability of its configuration throughout the lifecycle (Sommerville). | X |
| Conflict-resolution modes | Forcing (win–lose), accommodating (lose–win), avoiding (festers), compromising (partial win) and collaborating (win–win, preferred). | V |
| Contingency plan | The actions to take if a risk occurs; a fall-back plan says what to do if the contingency plan fails. | IV |
| Continuous delivery | An automated pipeline that keeps every change releasable, with a manual gate before production allowed. | X |
| Continuous deployment | Releasing every change that passes the automated tests to production automatically, with no human gate. | X |
| Continuous integration (CI) | Every commit builds the whole application and runs a comprehensive automated test suite; if the build fails, the team stops and fixes it immediately. | VII, X |
| Copyright (software) | Under the Copyright Act 1968 a program is a literary work, protected automatically; copyright covers expression, not ideas. | IX |
| Cost of conformance | Money spent on purpose to get the product right: quality planning, training, reviews, testing and similar prevention and appraisal work. | VII |
| Cost of Delay (CoD) | In WSJF, user/business value + time criticality + risk reduction/opportunity enablement, all as relative scores. | XI |
| Cost of nonconformance | The cost of failures and unmet quality expectations: internal failure before release and external failure after it. | VII |
| Cost of quality | The cost of conformance (prevention and appraisal) plus the cost of nonconformance (internal and external failure). | VII |
| Cost Performance Index (CPI) | EV/AC, the value earned per dollar spent; below 1 means over budget. | VIII |
| Crashing | Shortening the project by shortening the critical path; in PMBOK terms, adding resources to critical tasks at least extra cost. | VIII |
| Critical path | The longest path through the network; its activities have zero total float, so any delay to them delays the project. | VIII |
| D | ||
| Daily Scrum | A 15-minute daily event in which the Developers inspect progress toward the Sprint Goal and adapt their plan. | III |
| Defect removal efficiency (DRE) | The share of all defects removed before production, e.g. 54 of 58 = 93.1%. | VII |
| Defined process control | Controlling a process by fixing its steps in advance, so the same inputs give the same output; suits predictable work (e.g. waterfall, V-model). | II |
| Definition of Done (DoD) | The formal description of the quality an Increment must meet; work that does not meet it is not released or shown. | III, VI |
| Definition of Ready (DoR) | The entry check for a story: design specs provided, small, ACs agreed, testable and estimated. | VI |
| Delayed issue effect (DIE) | The claim that an issue gets harder to fix the longer it lingers; Menzies et al. (2016) found no consistent increase on 171 TSP projects. | VII |
| Delphi technique | Risk identification in which experts answer individually, see each other's answers anonymously, and revise over rounds until they reach consensus. | IV |
| Derivation history | The recorded chain of changes from which a version was derived, with their rationale. | X |
| Derived CI | A CI generated automatically from other CIs, such as a compiled file or build package; it must be reproducible. | X |
| Developers | The Scrum Team members (2020 Guide term) who create the usable Increment and own the Sprint Backlog. | III |
| Dis-benefit | An outcome of a project that someone will see as negative, such as disruption, retraining or extra maintenance. | I |
| Discount factor (DF) | 1/(1 + r)^t: the multiplier that converts money received in year t into today's value at rate r; year 0 has DF = 1. | I |
| Discounted payback | The time until cumulative discounted cash flow turns positive; always later than simple payback. | XII |
| Distributed team | A team spread across locations that relies on communication technology; also called a virtual or remote team. | V |
| Document-driven | Moving between phases by completing documents; makes late change costly because every affected document must be updated. | II |
| E | ||
| Earned value (EV) | The budgeted value of the work actually completed to date (old name BCWP). | VIII |
| Effort | The amount of work in a task, measured in person-months, as opposed to its elapsed duration. | VIII |
| Empirical process control | Controlling a process by observation, inspection and adaptation in short cycles; suits complex, volatile, novel work (e.g. Scrum). | II, III |
| Enabler | A backlog item with no direct user function (architecture, infrastructure, compliance or exploration) that extends the architectural runway. | XI |
| Engagement assessment matrix | PMBOK table recording each stakeholder's current (C) and desired (D) engagement level; the gaps drive engagement actions. | V |
| Engagement levels | Unaware, resistant, neutral, supportive and leading: how aware of and committed to a project a stakeholder is. | V |
| Epic | A large user story, generally taking more than one or two sprints, that is split until each story fits in one sprint. | VI |
| Error log | A running list of revision mistakes and their causes, used to choose what to re-study. | XII |
| Escalation ladder | Raising an ethical concern one step at a time: the person involved, the PM in writing, senior management, the client, a regulator, and as a last resort refusing or resigning. | IX |
| Essential SAFe | SAFe's smallest configuration: the minimum roles, events and artefacts needed to deliver through one Agile Release Train. | XI |
| Estimate at completion (EAC) | The forecast final cost, AC + (BAC − EV)/CPI, which equals BAC/CPI. | VIII |
| Ethical dilemma | A situation where the options pull in different directions, such as instructions or deadlines against duties to others. | IX |
| Ethics | The principles and values an individual uses to govern their actions and decisions. | IX |
| Evolutionary development | Build a version from outline requirements, let the customer use it, and let feedback define the next version, so requirements emerge (Boehm 1988). | II |
| Evolutionary prototype | A prototype built to production quality and grown into the final system. | II |
| Exam hurdle | The minimum of 25/50 on the exam needed to pass the subject, whatever the assignment marks. | XII |
| Exploit / enhance / share | Opportunity strategies: make the opportunity certain; raise its probability and positive impact; give ownership to a third party. | IV |
| External failure | The cost of defects found after release, such as patches, support, lost sales, lost reputation, lawsuits and harm. | VII |
| Extreme Programming (XP) | Kent Beck's engineering-focused agile methodology: weekly iterations and prescribed practices such as pair programming, TDD and continuous integration. | III |
| F | ||
| Fast-tracking | Overlapping or parallelising activities that were planned in sequence, at the risk of rework. | VIII |
| Feature | A service or capability that fulfils a stakeholder need, fits in one PI, is owned by Product Management and has a benefit hypothesis and acceptance criteria. | XI |
| Finish-to-start dependency | The most common dependency type: the successor can't start until the predecessor finishes. | VIII |
| Fishbone diagram | A cause-and-effect (Ishikawa) diagram that sorts the possible causes of a problem into categories, drawn as bones leading to the problem at the head. | VIII |
| Fixed-date release planning | Planning in which the release date is fixed and scope flexes to fit velocity × sprints remaining. | XII |
| Fixed-price contract | A contract with an agreed price for defined deliverables, so the contractor carries the cost-overrun risk. | IX |
| Fixed-scope release planning | Planning in which the required scope is fixed and its story points ÷ velocity set the number of sprints. | XII |
| Forward pass | Working left to right through a network to find each task's early start (the maximum EF of its predecessors) and early finish. | VIII |
| Free float | How long a task can be delayed without delaying any successor: earliest successor ES − EF. | VIII |
| Function point | A measure of functional size from the user's view, counted from inputs, outputs, inquiries, internal files and interface files. | VIII |
| Functional configuration audit | An audit of whether a CI does what its requirements specify, using test results and traceability. | X |
| G | ||
| Given/When/Then | The behaviour-driven format for acceptance criteria: Given a condition, When an event happens, Then an observable result follows. | VI, XII |
| Groupthink | Pressure for unanimity and self-censorship caused by too little conflict; countered by a safe climate and a devil's advocate. | V |
| H | ||
| Honesty (ACS 2.1) | ACS value with clauses (a)–(c): be truthful, do not misrepresent (even by omission), and do not remain silent about unprofessional conduct. | IX |
| Hybrid approach | A blend of plan-driven and agile practice, used when only some agile assumptions hold; possible because agility is not binary. | III |
| Hybrid model | A tailoring that combines approaches, e.g. a client's mandated phase gates with agile delivery inside; not a formal SDLC. | II |
| I | ||
| IEEE-CS/ACM Software Engineering Code | An international code with eight principles: Public, Client and Employer, Product, Judgment, Management, Profession, Colleagues and Self. | IX |
| IID | Iterative and incremental development: building a system in repeated cycles that each add to it; dates back to the 1950s. | II |
| Increment | An additive, verified, usable step toward the Product Goal; its commitment is the Definition of Done. | III, VI |
| Incremental model | Capture requirements up front, then build and deliver the system as operational slices through a series of mini waterfalls (A, A+B, A+B+C). | II |
| Information sclerosis | Boehm's term for temporary workarounds hardening into fixed constraints that can no longer be changed. | II |
| Inspect & Adapt (I&A) | The end-of-PI workshop where the ART reviews the PI System Demo, measures objectives and runs a problem-solving workshop to improve product and process. | XI |
| Inspection (Fagan) | The most rigorous formal review: led by a moderator who is not the author, with mandatory checklist-based preparation, aiming at maximum defect detection. | VII |
| Integration management | The knowledge area that coordinates all the others, from Develop Project Charter to Close Project or Phase. | I |
| Internal failure | The cost of defects found before release, such as rework, re-testing and schedule slip. | VII |
| INVEST | Criteria for a good user story: Independent, Negotiable, Valuable, Estimable, Small and Testable. | VI |
| IP iteration (Innovation & Planning) | The last iteration of a PI, holding the Inspect & Adapt workshop, the next PI Planning, innovation time and a buffer. | XI |
| ISO 9001 | The ISO standard of quality management system requirements that organisations are certified against; certification does not show a product is good. | VII |
| ISO/IEC 25010 | The current product quality model; its 2023 edition has nine characteristics, including interaction capability, flexibility and the new safety. | VII |
| Issue | An event that is certain or has happened (p = 1), to be dealt with now rather than planned for as a risk. | IV |
| Iteration | SAFe's name for a sprint; every team on the train shares the same iteration length and dates. | XI |
| Iterative | Repeating cycles to rework something; agile is iterative and incremental. | II |
| J | ||
| Just barely good enough (JBGE) | Agile documentation principle: enough documentation to support the project without burdening the team. | V |
| K | ||
| Kanban | A pull-based flow method from Toyota's lean manufacturing that visualises work on a board and limits work in progress to cut lead time. | III |
| Kick-off meeting | The meeting at the end of planning that communicates objectives, gains the team's commitment and explains each stakeholder's role. | V |
| Knowledge areas | PMBOK's fields of PM expertise: older editions have four core (scope, time, cost, quality), four facilitating and integration; newer ones list ten. | I |
| L | ||
| Lead time | The time from when a work item is requested to when it is finished. | III |
| Least-cost crashing | Shortening critical tasks one cheapest day at a time while the crash cost per day is below the indirect cost per day. | XII |
| Liquidated damages | A pre-agreed sum a contractor pays for a specified breach, usually late delivery; it must be a genuine pre-estimate of loss, not a penalty. | IX |
| LockDown Browser | A locked-down browser in which the Canvas exam runs, so the laptop can reach nothing but the exam. | XII |
| M | ||
| Macro-ethics | The ethics of big public issues that affect many people, such as Cambridge Analytica or the Boeing 737 MAX. | IX |
| Matrix organisation | A structure in which staff report to both a functional manager and a project manager, giving them 'two bosses'. | I |
| McCall's quality model | A hierarchy of 11 quality factors in three perspectives (product operation, revision and transition), broken into criteria and metrics. | VII |
| Mehrabian's 7–38–55 rule | Words 7%, tone 38%, body language 55% of meaning, valid only for inferring feelings when words and cues conflict. | V |
| Merge activity | An activity with two or more immediate predecessors, where paths join. | VIII, XII |
| Meta-model | A model for generating models: the spiral becomes waterfall-like, evolutionary or a mix depending on the project's risks. | II |
| Method | A way of doing the work inside one phase (how), as opposed to a process model, which says what comes next and for how long. | II |
| Micro-ethics | The ethics of day-to-day decisions and interactions at work, such as skipping a test or overstating progress. | IX |
| Milestone | The completion of an activity that evidences a deliverable or the end of a phase; an event of zero duration. | VIII |
| Misrepresentation by omission | Creating a false impression by leaving something out; forbidden by ACS clause 2.1(b). | IX |
| Moderator | The review leader in an inspection, who plans it, chairs the meeting, keeps it on defects, decides the outcome and checks the rework. | VII |
| Moral rights | An author's non-transferable rights of attribution, against false attribution, and of integrity in the work. | IX |
| MoSCoW | A prioritisation scheme: Must (missing one = failure), Should (critical but not a failure condition alone), Could (dropped first), Won't (not this time). | VI |
| Multiple-choice question (MCQ) | An exam question with exactly one correct option, worth 2 marks in SWEN90016. | XII |
| Multiple-response question (MRQ) | An exam question with 2 or 3 correct options, worth 3 marks, where each wrong tick cancels a right one. | XII |
| N | ||
| Net Present Value (NPV) | The sum of each year's net cash flow discounted to today's value; accept a project if NPV > 0 and prefer the higher NPV. | I |
| Notifiable Data Breaches (NDB) scheme | The part of Australia's Privacy Act that requires serious data breaches to be reported to affected people and the regulator. | IX |
| O | ||
| Operations (Business As Usual) | Ongoing, repetitive work with no planned end, such as a help desk or payroll; projects hand their products over to it. | I |
| Opportunity | A risk whose effect on the project objectives would be positive. | IV |
| Organisational ethics | The values an organisation expresses to its employees and other parties, irrespective of governmental or regulatory law. | IX |
| P | ||
| Pair programming | Two programmers working at one keyboard, so code is reviewed continuously as it is written. | III, V |
| Pareto analysis | Sorting defect categories by count, with a cumulative-percentage line, to find the vital few causes that produce most defects (the 80/20 rule). | VII |
| Partial marking | Marking that gives credit for a partly right written answer or a correct method with a slip; a blank never scores. | XII |
| Payback period | The time until cumulative net cash flow reaches zero: years before break-even plus the unrecovered amount divided by the break-even year's net flow. | I |
| Persona | A named, imaginary individual with a background and goals who represents a user role (Cohn). | VI |
| Phase gate (kill point) | A management review at the end of a phase that re-checks the business case and makes a go/no-go decision before more money is committed. | I |
| Physical configuration audit | An audit of whether a CI is built as documented, comparing delivered items and versions with the documentation. | X |
| PI objectives | Each team's and the ART's goals for a PI in business language, scored 1–10 for value by Business Owners and marked committed or uncommitted (stretch). | XI |
| PI Planning | A two-day event held every PI in which all ART teams plan together, preferably in person, and commit to PI objectives. | XI |
| Plan-driven | An approach where work follows a plan made up front, controlled by documents and change control (defined control). | II |
| Planned value (PV) | The authorised budget for the work scheduled to date (old name BCWS). | VIII |
| Planning poker | Group estimation where everyone reveals a card at once, the lowest and highest voters explain, and the team re-votes until consensus. | VI |
| Planning quality | Identifying which quality standards are relevant to the project and how to satisfy them; its output is the Software Quality Plan. | VII |
| PNR curve | The Putnam–Norden–Rayleigh curve: effort and delivery time trade off steeply, so compressing a schedule below about 0.75 of nominal is impossible. | VIII |
| Portfolio | The whole set of an organisation's projects and programmes; screening and selection happen at this level. | I |
| Power/interest grid | A 2×2 grid placing stakeholders by power and interest: manage closely, keep satisfied, keep informed, or monitor. | V |
| Predecessor subject | An earlier University of Melbourne subject (433-443, 433-341) whose past papers are used for practice; no SWEN90016 paper exists. | XII |
| Privacy by design | Building privacy into a system's defaults from the start, collecting only needed data and using it only for its stated purpose. | IX |
| Process | A systematic series of actions or steps taken to achieve a specific goal; reusable across many projects (e.g. Scrum). | I, II |
| Process groups (PMBOK) | Initiating, planning, executing and closing in sequence, with monitoring and controlling running alongside them. | I |
| Process model | A simplified description of the steps to reach a goal; per Boehm it fixes the order of stages and the transition criteria between them. | II |
| Product | The output of a process; in software, the system plus its artefacts such as documents, tests and manuals. | I |
| Product Backlog | The emergent, ordered list of what is needed to improve the product; its commitment is the Product Goal. | III, VI |
| Product backlog item (PBI) | One entry in the product backlog, usually a user story or an epic, carrying business value from the customer's view. | VI |
| Product Goal | A future state of the product that is the Scrum Team's long-term objective; the commitment for the Product Backlog. | III, VI |
| Product Management | The ART-level role that owns, defines and prioritises the Program Backlog of Features; the Product Owner scaled up. | XI |
| Product Owner | The one person accountable for maximising product value and for managing and ordering the Product Backlog; only the PO can cancel a Sprint. | III |
| Product-specific risk | A risk tied to this product and its technology, which only people who understand them can spot (contrast generic risks common to all projects). | IV |
| Program Backlog (ART Backlog) | The single, prioritised list of Features for the whole train, owned by Product Management; it drives PI Planning. | XI |
| Program board | The PI Planning board (ART planning board in SAFe 6.0) showing which team delivers each Feature in which iteration, milestones, and dependencies as strings. | XI |
| Program Increment (PI) | An 8–12 week timebox (default 10 weeks: four iterations plus an IP iteration) in which an ART delivers working, tested value; called Planning Interval since SAFe 6.0. | XI |
| Programme | A group of related projects managed together so that they deliver shared benefits. | I |
| Progressive planning | Adding detail level by level, just in time: features in the Vision & Scope, PBIs (the what) in the product backlog, tasks of one day or less (the how) in the sprint backlog. | VI |
| Project | A temporary endeavour to create a unique product, service or outcome (PMBOK); it brings change, is cross-functional and deals with the unknown. | I |
| Project / product / business risk | Risks that affect, respectively, the planning (budget, schedule, scope, people), the quality or performance of the product, and the project's economic success. | IV |
| Project charter | The document issued by the sponsor that formally authorises a project and gives the PM authority to apply organisational resources. | I |
| Project management | Planning, delegating, monitoring and controlling a project, and motivating those involved, to hit targets for time, costs, quality, scope, benefits and risks. | I |
| Project Management Plan (PMP) | The formal, approved document, owned by the PM, that defines how a project is executed, monitored, controlled and closed; the one source of truth. | V |
| Project schedule | The living planning artefact holding task durations and dependencies, resources, milestones and deliverables, and the timeline; it answers how long and how much. | VIII |
| Prototype | An early, partial version of the software built to learn and reduce risk, e.g. to clarify requirements, explore usability or test new technology. | II |
| Pull request | A request to merge a branch that peers review and CI tests first, acting as lightweight change control. | X |
| Q | ||
| Quality assurance (QA) | Process-focused, preventive quality work: choosing standards and defining processes, V&V and testing so the project will meet its quality standards. | VII |
| Quality control (QC) | Product-focused, detective and corrective work: monitoring specific results (reviews, tests, audits, defect analysis) to check they comply with the standards. | VII |
| R | ||
| Rapid prototyping | A client-oriented cycle of prototype, review and refine, where the prototype is a working model of a subset of the product. | II |
| Release | A set of increments shipped to the customer, defined by date, theme and feature set, with date and quality fixed and scope variable. | VI, X |
| Release Train Engineer (RTE) | The train's servant-leader and "Chief Scrum Master": facilitates ART events, manages cross-team dependencies and risks, and coaches; never assigns work. | XI |
| Requirement | A statement of what the system should do; the basis for judging completeness and correctness, and every requirement should be tested. | VI |
| Residual risk | The risk that remains after mitigation: the same event with lower exposure, which must be analysed again. | IV |
| Resource levelling | Delaying non-critical tasks within their float so that resource demand never exceeds availability. | VIII |
| Respect for Others (ACS 2.3.1) | ACS value with clauses (a)–(g): minimise and mitigate harm to stakeholders, fairness, inclusivity, a respectful workplace, and others' IP. | IX |
| Respect for the Profession (ACS 2.3.2) | ACS value with clauses (a)–(h): public interest, sustainability, public education and the standing of the ICT profession. | IX |
| Return On Investment (ROI) | In the slides' version, (total discounted benefits − total discounted costs) / total discounted costs, compared with a hurdle rate of typically 11–14%. | I |
| Risk | An uncertain event or condition that, if it occurs, has a positive or negative effect on the project objectives (PMBOK). | IV |
| Risk audit | An external team's check of how complete risk identification was and that risk procedures exist. | IV |
| Risk exposure (RE) | Probability times impact (RE = P × I), the expected loss from a risk; used to rank risks. | IV |
| Risk Management Plan (RMP) | The output of the Plan step, setting out risk methodology, roles, budget, categories, probability and impact scales, tracking, and contingency and fall-back plans. | IV |
| Risk matrix | A 3 × 3 grid that rates a risk Low, Medium or High from its likelihood and impact, making risks visible. | IV |
| Risk reduction leverage (RRL) | (RE before − RE after) / cost of the response; a response is worth doing if RRL > 1. | IV, XII |
| Risk register | The risk response plan, recording each risk's ID, trigger, owner, response and resources required. | IV |
| Risk statement | A risk written as ACTION – CONSEQUENCE – IMPACT (or EVENT – CAUSED BY – CONSEQUENCES), so it can be scored. | IV |
| ROAM | Classifying each risk as Resolved, Owned, Accepted or Mitigated, so that none is left unowned. | XI |
| Rough Order of Magnitude (ROM) | A very early, low-accuracy estimate used to screen ideas, with a range of −25% to +75% (PMBOK). | I |
| Royce's five fixes | Program design first, document the design, do it twice, plan/control/monitor testing, and involve the customer (Royce 1970). | II |
| S | ||
| SAFe (Scaled Agile Framework) | A framework (v6.0) that scales Agile practice across many teams building one large product, combining Agile, Lean and DevOps principles. | XI |
| Schedule Performance Index (SPI) | EV/PV; below 1 means behind schedule. | VIII |
| Scope creep | Uncontrolled growth of a project's scope as small additions pile up without matching changes to time or budget. | I, IV |
| Scrum | A lightweight framework that helps people, teams and organisations generate value through adaptive solutions for complex problems (Scrum Guide 2020). | III |
| Scrum Master | The servant leader accountable for establishing Scrum and the Scrum Team's effectiveness; does not assign tasks. | III |
| Scrum of Scrums | A weekly meeting of team Scrum Masters or representatives, facilitated by the RTE, on cross-team dependencies, risks, blockers and progress (Coach Sync in SAFe 6.0). | XI |
| Scrum pillars | Transparency, inspection and adaptation, the three pillars of Scrum's empiricism. | III |
| Scrum-but | Claiming to do Scrum while skipping or changing parts of it, such as varying Sprint lengths or skipping Retrospectives. | III |
| SDLC | Software/systems development life cycle: a process for planning, creating, testing and deploying an information system; used interchangeably with 'process' in this subject. | II |
| Semantic versioning | MAJOR.MINOR.PATCH numbering: MAJOR for breaking changes, MINOR for compatible features, PATCH for compatible fixes, resetting lower fields. | X |
| Servant leadership | Leadership that serves first: sharing power, putting others' needs first and helping people grow (Greenleaf 1970); the Scrum Master's style. | I, III |
| Shannon communication model | Information source, transmitter, channel, receiver and destination, with noise corrupting the signal; the PM version adds feedback and context. | V |
| Shift-left testing | Moving testing earlier and doing it more often, with testers involved from requirements onwards. | VII |
| Software configuration | The total of all a project's artefacts, their current state, and the dependencies between them. | X |
| Software crisis | The 1960s problem of large software projects shipping late, over budget or not working, named at the 1968-69 NATO conferences. | II |
| Software quality | Conformance to requirements (Crosby), fitness for use (Juran), or the degree to which a system satisfies the stated and implied needs of its stakeholders (ISO/IEC 25010). | VII |
| Software Quality Plan (SQP) | The plan, in six parts, that sets a project's quality goals, QA processes, standards and quality risks; also called the SQAP. | VII |
| Spike | A time-boxed research backlog item used in Scrum to reduce uncertainty on a high risk. | IV |
| Spiral model | Boehm's risk-driven SDLC: each loop sets objectives, resolves the highest remaining risks (often by prototyping), develops and verifies, then plans and commits to the next loop. | II |
| Sponsor | The senior person who funds and champions a project, owns its business case and issues its charter. | I, V |
| Sprint | A fixed-length cycle of one month or less that contains all other Scrum events; the next starts immediately after the last. | III |
| Sprint Backlog | The Sprint Goal plus the selected items plus the Developers' plan; its commitment is the Sprint Goal. | III, VI |
| Sprint Goal | The single objective of a Sprint, set at Sprint Planning; fixed, while the work to meet it is negotiable. | III, VI |
| Sprint Retrospective | The event that concludes the Sprint, where the team plans improvements to quality and effectiveness. | III |
| Sprint Review | The event where the Scrum Team and key stakeholders inspect the Sprint's outcome and adapt the Product Backlog; a working session. | III |
| SRS | Software Requirements Specification: the precise, agreed statement of what the software must do, output by the analysis phase. | II |
| Stakeholder | Any individual, group or organisation that may affect, be affected by, or have an interest in a project or its outcome. | V |
| Stakeholder register | A table listing each stakeholder's name, position, internal/external status, project role and contact. | V |
| Start-to-Finish dependency | The predecessor must start before the successor can finish (not 'finish before start', which is Finish-to-Start). | XII |
| Status accounting | Recording and reporting the state of CIs, baselines and change requests to give visibility and traceability. | X |
| Story points | A unitless measure of a story's relative effort, combining size, complexity and uncertainty; never equated to hours. | VI |
| SWOT analysis | Analysis of internal strengths and weaknesses and external opportunities and threats; it finds positive as well as negative risks. | IV |
| System Architect/Engineer | The ART-level role that gives architectural guidance and aligns teams with enterprise standards; it has no Scrum analogue. | XI |
| System Demo | A demonstration of the integrated work of all ART teams to Business Owners, Product Management, the RTE and stakeholders. | XI |
| System Team | A team on the train whose job is integration and DevOps for all the other teams, as in the CareConnect+ example. | XI |
| T | ||
| T-shirt sizing | Fast, informal estimation into sizes XS to XXL, which must be converted to numbers before velocity can be charted. | VI |
| Tag | An immutable label on a commit that marks a baseline or release, such as v1.2. | X |
| TDD | Test-driven development: write a failing unit test, then just enough code to pass it, then refactor (red, green, refactor). | VII |
| Team | A group that is cohesive and focused on a common purpose or goal. | V |
| Team Backlog | Each team's list of Stories, owned by its Product Owner, filled from Features at PI Planning. | XI |
| Teamicide | DeMarco and Lister's seven practices that kill teams: defensive management, bureaucracy, physical separation, fragmented time, quality-reduced product, phony deadlines, clique control. | V |
| Technical debt item | A visible backlog item recording work deliberately left incomplete, such as a mock-up to be finished later. | XII |
| Threat | A risk whose effect on the project objectives would be negative. | IV |
| Three-point estimate | An estimate made from optimistic, most likely and pessimistic values; PERT combines them as TE = (O + 4M + P)/6. | VIII |
| Throwaway prototype | A prototype built fast and discarded once it has answered its question; never production quality. | II |
| Time and materials contract | A contract in which the client pays actual effort at agreed rates plus expenses, so the client carries the cost-overrun risk. | IX |
| Timebox | A fixed maximum duration for a Scrum event, e.g. 8 hours for Sprint Planning in a one-month Sprint. | III, VI |
| Total float | How long a task can be delayed without delaying project completion: LS − ES. | VIII |
| Traceability | Being able to follow each requirement to the design that meets it and the test that checks it, in both directions. | II |
| Trigger | The sign that a risk has occurred or is about to, watched during monitoring. | IV |
| Triple constraint (iron triangle) | The slides' triangle of Resources (cost), Scope and Time, with quality in the middle: change one side and another must change, or quality suffers. | I |
| Trustworthiness (ACS 2.2) | ACS value with clauses (a)–(h): accountability, integrity, learning, privacy, honest capabilities, competence and robust, secure systems. | IX |
| U | ||
| Uncertainty | Lack of complete knowledge about an outcome (0 < p < 1); it becomes a risk only if it has an impact on you. | IV |
| Undue influence | Pressure from a boss, client or colleague to act against the Code; resisting it is part of integrity, ACS clause 2.2(b). | IX |
| User journey map | A Sprint Review aid with 8 elements: persona, scenario, stages, actions, thoughts, emotional experience, opportunities and internal ownership. | VI |
| User story | A short description of a feature from the user's perspective: As a [role], I want to [goal], so that [benefit]. | VI |
| V | ||
| V-model | A waterfall variant pairing each development phase with a test level that is planned during that phase and later verifies it. | II |
| Valid schedule | A feasible schedule: dependencies respected, no over-allocation, validated effort, full WBS coverage with owners, and fixed dates met. | VIII |
| Validation | Checking that you are building the right system, by comparing the product with stakeholder needs, with users or the client involved. | VII |
| Variant | A CI that is functionally identical to another but differs in a non-functional aspect such as platform or language. | X |
| Velocity | Story points of Done stories completed per sprint; optional and team-internal, with no partial credit. | VI |
| Verification | Checking that you are building the system right, by comparing one artefact with another (e.g. design against requirements). | VII |
| Version | A functionally different state of a CI caused by development changes. | X |
| Version control | The process of managing and tracking changes to configuration items over time. | X |
| Version description document (VDD) | A document recording what each release contains. | X |
| W | ||
| Walkthrough | A formal review led by the author, with no preparation, in which defects are found and solutions discussed. | VII |
| Waterfall | A plan-driven, document-driven SDLC whose distinct phases run once in sequence without overlap, each producing a reviewed document. | II |
| Weighted scoring model | A selection method that multiplies each project's 1–10 score on each criterion by the criterion's weight (weights sum to 1) and ranks by the total. | I |
| WIP limit | The maximum number of work items allowed in a stage of a Kanban board at once; it prevents overload and exposes bottlenecks. | III |
| Work Breakdown Structure (WBS) | A hierarchical decomposition of the total scope of work into work packages, each with a verifiable outcome. | VIII |
| Work package | The lowest level of a WBS: a piece of work that can be estimated, owned by one person and tracked, typically 8–80 hours. | VIII |
| WSJF (Weighted Shortest Job First) | A prioritisation rule: WSJF = Cost of Delay ÷ Job Size, doing the highest-scoring job first. | XI |