SWEN90016 Software Processes and Management
The Complete Exam Bible · S2 2026SWEN90016 Overview
- Graduate coursework
- Semester 2, 2026
- Software project management
- Team delivery
Software Processes and Management study route
Software Processes and Management is mapped from the current Semester 2, 2026 teaching sequence. The 6 chapters follow the evidence available for this offering, with deeper pages assigned to topics carrying more calculation, comparison or boundary work.
- Process follows uncertainty Select lifecycle controls from project evidence and risk.
- Ownership must be visible Risks, decisions and communication need named owners.
- Three hurdles apply Overall, combined-assignment and examination thresholds must be met.
- Govern work through visible ownership Connect each process artefact to a project decision, named owner, review trigger and observable delivery consequence.
How SWEN90016 is assessed
| Component | Weight | Format |
|---|---|---|
| Assignment 1 | 15% | Individual assignment of approximately 750–900 words |
| Assignment 2 | 35% | Group project with planning, development, reflection and demonstration artefacts |
| Final Exam · hurdle | 50% | Individual final examination |
The current assessment page publishes Assignment 1 at 15%, Assignment 2 at 35% and the Final Exam at 50%. It also states overall, combined-assignment and final-exam hurdles.
Assessment structure
Segment widths reproduce the published percentage weights and total 100%.
What SWEN90016 covers
Six chapters move from process choice and risk to communication, agile planning, assurance and scaled delivery.
Project Framing and Software Process Choice
Define outcomes, constraints and governance before selecting a lifecycle02Risk Identification, Analysis and Response
Turn uncertain events into owned, monitored response decisions03Stakeholders, Roles and Communication Planning
Map influence, information needs and accountable decisions04Agile Estimation, Planning and Team Flow
Use relative estimates and observed flow without turning them into promises05Quality, Configuration and Professional Ethics
Integrate acceptance evidence, version control and professional responsibility06Scaled Delivery and Integrated Project Control
Coordinate teams without hiding dependencies behind framework labelsBegin with the published assessment table, select the chapter that matches the task, retrieve the governing concepts, complete a changed case and verify the final claim.
The recurring method is frame the project objective, select a process from uncertainty and governance evidence, make ownership visible and adapt from feedback. Definitions, worked explanations, numerical checks and diagrams serve that method.
Practice cases are written for study and are not official questions or marking schemes. Current dates, submission settings and permitted resources remain controlled by the University learning system and timetable.
Project Framing and Software Process Choice
The opening sequence introduces software project management and contrasts software-development lifecycle processes.
Use this chapter to match a software process to uncertainty, feedback cadence, compliance and delivery risk Keep A familiar lifecycle is not automatically suitable; the choice must follow project evidence and be revisited when uncertainty changes.
Risk Identification, Analysis and Response
The third teaching block covers software risk management and applies it in the tutorial case.
Use this chapter to write actionable risk statements, prioritise them and connect each response to a trigger and owner Keep A colour or score communicates priority only after scales, time horizon and response assumptions are defined.
Stakeholders, Roles and Communication Planning
Week 4 combines project planning, stakeholder management, communication management and executive roles.
Use this chapter to select communication content, channel, cadence and owner for stakeholders with different decision rights Keep Frequent communication can still fail when it carries the wrong evidence, reaches the wrong role or leaves a decision unowned.
Agile Estimation, Planning and Team Flow
Week 5 covers agile planning, estimation, teams and common planning pitfalls.
Use this chapter to plan a sprint from prioritised work, capacity and uncertainty while preserving quality and learning Keep Velocity is team- and context-specific historical evidence; it is not a productivity target or a conversion rate between teams.
Quality, Configuration and Professional Ethics
The middle and later schedule includes software quality, ethics and configuration management.
Use this chapter to design controls that make product quality, change history and professional consequences visible Keep Passing tests does not prove fitness for purpose, and traceable changes do not make an unethical product acceptable.
Scaled Delivery and Integrated Project Control
The later schedule includes scaled agile practice, team consultation and integrated project artefacts.
Use this chapter to connect portfolio intent, team work, integration evidence and stakeholder feedback across scale Keep Scaling adds coordination cost; a framework is useful only when its roles and events solve observed dependency or governance problems.
Evidence and assessment control
The current assessment page publishes Assignment 1 at 15%, Assignment 2 at 35% and the Final Exam at 50%.
It also states overall, combined-assignment and final-exam hurdles. Every percentage shown in the table comes from current official material.
Where a pass condition applies across tasks rather than to one component, it is stated separately instead of attaching an inaccurate hurdle badge to a row.
SWEN90016 retrieval workshop
Worked check. Use frame the project objective, select a process from uncertainty and governance evidence, make ownership visible and adapt from feedback.
Write the decisive relationship, verify its boundary and explain what would change the conclusion.
Classification practice. Choose one chapter and identify the first decision its method controls.
Transfer practice. Change one fact and retrace the first affected relationship without discarding premises that remain valid.
Verification practice. Compare the final claim with its calculation, evidence and stated boundary before treating it as complete.
Use retrieval, transfer and repair
After reading a chapter, close the page and reconstruct the definitions, mechanism, check and boundary.
Change one fact, identify the first affected inference and repair only that step. This makes revision sensitive to the reason an answer works rather than merely familiar with its wording.
Software delivery control case
- 2Separate discovery, assurance and integration constraints.
- 3Choose lifecycle and feedback controls for each.
- 3Assign owners, triggers and review evidence.
Key terms
- Lifecycle Model
- A lifecycle model organises how software work progresses, receives feedback and produces assurance evidence.
- Risk Owner
- A risk owner is accountable for monitoring a risk and ensuring the agreed response occurs.
- Velocity
- Velocity is a team-local historical measure of completed relative estimates over a sprint.
- Configuration Baseline
- A configuration baseline identifies the approved set of artefacts used for testing or release.
- Value Stream
- A value stream is the end-to-end flow through which work produces an outcome for a stakeholder.
SWEN90016 FAQ
How do I frame a difficult software-process problem?
Identify the requested decision, list supplied facts, select the governing software-process concept and show the relationship that changes the result. Finish by testing one boundary rather than adding unrelated detail.
On which page are current software deadlines confirmed?
Use the current Canvas page and official timetable for software-process. Published weights and stable concepts remain useful here, while operational dates and submission settings stay controlled by the live University system.
What makes revision active for software processes?
Reconstruct the software-process chapter map without notes, apply project framing, process selection and feedback control to a changed case, and record the first failed move. Correcting that move builds transfer better than rereading a polished answer.
Have the practice cases come from assessed work?
The software-process cases are independent study exercises designed to expose reasoning, calculation and boundary checks. They are not University questions, solutions, rubrics or predictions of what will be assessed.
How much should a final software answer include?
For a software-process response, state the classification or model, show the decisive working, interpret the result in context and name the assumption or evidence that could change it. Keep administrative claims tied to current University instructions.
Which evidence controls a changed Software Processes and Management case?
Use the facts supplied in the case, the governing Computer Science concept and the chapter boundary. If an administrative setting or date affects the answer, confirm that setting on the current University site before relying on it.
How to study for the exam
Practise choosing processes from project evidence, convert risks into owned actions, and connect every project artefact to a decision or assurance need.
Your AI Computer Science tutor for SWEN90016
Stuck on a hard SWEN90016 question? Sia is AskSia’s AI Computer Science tutor — ask any SWEN90016 Software Processes and Management question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.
