Session 1 overview
A practical, shareable planning dashboard built from your FYP project plan, assessment guidance, and a proposed four-member task split. Progress is shared live with the whole team and the supervisor; log in with the team password to edit.
Build one integrated human-in-the-loop IDS prototype.
AI detection → security alert → analyst correction → stored feedback → engineer evaluation, with administrator-configured thresholds and rules.
Session 1 ends19 DEC 2026
The Subject Outline indicates 19 December 2026, while a first-lecture table lists 12 December. Confirm Moodle/supervisor instructions. The progress documentation is due 12 December in the Subject Outline.
A working threat prediction appears in the analyst UI, can be reviewed and corrected, and is saved for model feedback. Include relevant admin and engineer screens, documentation, and testing.
Three immediate checkpoints
Intermediate dates are team targetsKickoff ready
Assign owners, create repository and backlog, agree on APIs, draft architecture, publish a simple website, and record first meeting.
PRD draft ready
Finish draft requirements, research, diagrams, wireframes and planning. Run an initial dataset/model experiment.
PRD submission
Submit finalized Project Requirements Documentation (10%) after supervisor review and correction.
Critical path
Do these in this orderDo not start with visual polish or login screens alone. The first demo should show the central IDS/feedback workflow working end-to-end.
The source project plan does not assign these technical workstreams. Use Member 1 through Member 4 for now, then agree on final ownership together. All members should help with documentation, testing and integration.
Member roster
Member numbers only — no names assigned yetPrimary workstreams
Ownership is a starting point, not a siloShared team rules
- Commit code, test results, diagrams or substantive documentation with traceable evidence.
- Maintain a short reflective diary every week.
- Review code and help integrate at the end of each sprint.
- Keep meeting agendas/minutes and an up-to-date product backlog.
- Demonstrate progress regularly to the supervisor.
- Resolve unequal workloads early, not at peer assessment.
This adapts the Excel project's sprint-based approach to your later practical kickoff. Phase dates below are proposed scheduling choices, except official assessment deadlines.
Phase-by-phase roadmap
Session 1 · ~9 weeksTarget checkpoints
One real model prediction reaches the analyst dashboard through the backend.
Correction is stored, visible in a feedback pool and available for an experiment.
Focus on fixes, tests, documents, and demo stability rather than new scope.
Tick tasks off when there is evidence (Git commit, diagram, document, test result or deployed feature). Progress is shared live: everyone, including the supervisor, sees the same state. Log in with the team password to tick tasks; each change is recorded against the member you select.
Team task tracker
Assessment dates and grading
Official dates from Subject Outline; verify any changes on Moodle| Date | Deliverable | Weight | Type |
|---|---|---|---|
| 31 Oct 2026 | Project Requirements Documentation (PRD) | 10% | Group |
| 12 Dec 2026 | Progress report: preliminary technical document, preliminary user manual, slides | 15% | Group |
| 19 Dec 2026* | Progress prototype presentation (approx. 20 minutes) | 10% | Group |
| 13 Feb 2027 | Final product and documentation | 45% | Group |
| 13 Feb 2027 | Consolidated reflective diary | 5% | Individual |
| 20 Feb 2027 | Final presentation | 15% | Group |
| 24 Feb 2027 | Final online document submission to SIM | — | Group |
*The first-lecture slide also lists 12 Dec for the prototype presentation, conflicting with the Subject Outline. Confirm the controlling date.
PRD checklist · due 31 Oct
Final scope must be agreed with supervisorRequirements must be testable.
Describe what the system does, for whom, when it happens, and how it will be verified. Separate minimum, optional and stretch features.
ADM-01: The administrator can change a global threat threshold and subsequent alert processing uses the updated value.
Example requirementENG-01: The model engineer can initiate an approved retraining job and compare evaluation metrics with the previous model.
Midpoint demo: proposed scope
Supervisor must confirm what is mandatory- Baseline ML model classifies sample traffic records.
- Prediction appears in an analyst alert feed.
- Analyst confirms/dismisses an alert and submits correction.
- Decision and feedback are stored with audit history.
- Basic role access, admin threshold, and whitelist logic are demonstrated.
- Engineer screen shows feedback pool and model metrics.
- Feature-level AI explanation for predictions.
- Retraining experiment with corrected labels and comparison.
- False positive reduction / analyst triage metrics with clearly defined calculation.
- CSV/JSON export of reviewed examples.
- Model versioning and rollback capability as time permits.
Submission package · December
- Updated requirements and WBS/Gantt
- Architecture, database and API design
- Use cases, UML activity/workflow, wireframes
- ML model pipeline and evaluation evidence
- Test plan, test cases, real test results
- Meeting minutes and decisions in appendix
- Functional live prototype on intended platform
- Preliminary user manual, screenshots, usage steps
- Presentation slides (~20-minute demo)
- Peer assessment / group contribution statement
- Project website and ongoing updates
- Individual reflective diaries kept weekly
10 October · first team meeting
Start with decisions, not just discussionSuggested meeting result
At the end, every member should leave knowing exactly what to deliver by 18 October, where their work will live, what the interface/API contracts are, and when the supervisor will review the decisions.
- Meeting date, attendees, and objective
- Decisions made and supervisor items
- Tasks assigned, owner, due date
- Risks/blockers and mitigation
- Next meeting date
Weekly working rhythm
Update your work
Commit changes, note unfinished tasks, prepare a demo, and update your own weekly diary with factual evidence.
Review and reprioritise
10m updates · 10m demo · 15m blockers · 15m next tasks · 10m minutes/backlog.
Present evidence
Walk through delivered features, documents, risks and questions. Record supervisor decisions and changes.
Supervisor questions to resolve early
Common risks and prevention
Run a baseline dataset/model experiment early; integrate inference before spending time polishing the UI.
Agree on common alert/feedback schema and APIs before coding different interfaces.
Preserve a held-out test set, report precision/recall/F1 and compare before/after; do not assume feedback improves performance.
Ask supervisor to approve core/nice-to-have/stretch items; prototype the critical workflow first.
Make one deployed shared build and run integrated smoke tests every sprint.
Keep weekly diaries, commits, meeting minutes and test records throughout the project.
Visible to the supervisor. Log in with the team password to upload, and pick who you are first so each file is attributed. Allowed: PDF, DOCX, XLSX, PPTX, MD, TXT, PNG, JPG (max 20 MB).
Upload a document
Log in (top right) to upload or delete documents.