Software Handover — Official Rules & Three-Audience Model
本页目录· 8 条
Academic integrity notice: the official 2026 S2 guideline states that Generative AI tools are not allowed in unit assignments unless the specific instructions permit them. This page records official requirements and a compliance checklist only. Do not use AI to draft, rewrite or generate the Handover Package.
Official assessment facts
- Assessment: Assignment 1F — Handover Package
- Weight: 10%
- Due: Week 11, Thursday 15 October 2026, 11:55 PM AEST
- Submit through the Project Governance Portfolio Repository and complete the Moodle plagiarism quiz.
- Unapproved late submission: 10% deduction per day, including weekends.
- The package needs a Monash mentor sign-off/acceptance facility adapted to the project.
- The PGP must use a meaningful folder convention and provide the Google Drive link.
Purpose
The package enables a new owner to take over, operate, support and improve the product without relying on the original team. It includes:
- a completed/tested product;
- packaging and a knowledge-transfer strategy;
- formal handover.
Three audiences and documents
1. Product Document — potential sponsor
Official guidance: approximately 1–5 pages, high-level and lean.
Check the official guideline for required items including:
- product, problem/reasoning, audience and importance;
- future sponsor/value and future possibilities;
- resources/people needed;
- ethical standards, Ethics Canvas link and ACS Code of Conduct alignment;
- team contact/LinkedIn details;
- build link/password and Product Video.
Use business language suitable for a time-poor decision-maker.
2. Support Document — operational/support staff
Purpose: “How do I run and support this product day to day?”
Official areas include:
- run/install/setup, data loading, backup and restore;
- software features and normal operating procedures;
- security, confidentiality and known vulnerabilities;
- integrations, data, APIs and industry standards;
- troubleshooting and common user issues;
- clear visuals/screenshots, training needs and recovery guidance.
3. Maintenance Document — technical/DevOps team
Purpose: “How do I fix, change or extend it?”
Official areas include:
- architecture, functions, source-code guidance and coding standards;
- setup, dependencies, integration, data, APIs and security;
- outstanding bugs, risks and known limitations;
- automated tests, deployment/CI/CD and operational monitoring;
- enhancement backlog and platform migration considerations;
- links to support information where responsibilities overlap.
Completion checklist
- Product, Support and Maintenance documents are distinct for their audiences.
- Instructions were tested by someone who did not write them.
- Build, credentials/access method and dependency ownership are verified.
- Known vulnerabilities, limitations and outstanding work are transparent.
- Sign-off facility is adapted and ready.
- Folder convention and Google Drive link are valid.
- Plagiarism quiz is complete.
- Entire package was produced without prohibited AI assistance.