Department of Computer & Information Sciences

Module Title: Advanced Programming
Module Code: KF7014
Academic Year / Semester: 2024–2025 / Semester 2
Module Tutor: Dr Maria Salama
Email: maria.salama@northumbria.ac.uk
Assessment Title: Summative Assessment – Development of Microservices-Based Application
Assessment Weighting:

• Individual Component: 60%
• Group Component: 40%

---

Key Dates

Event	Date	Time
Handout to Students	Week Commencing 3rd February 2025	–
Individual Component Submission	20th March 2025	4:00 PM
Group Component Submission	22nd May 2025	4:00 PM
Feedback and Marks Returned	Week Commencing 16th June 2025	–
Group Demonstrations	Week Commencing 26th May 2025	During working days (on campus)

---

Submission Guidelines

• Format:
  • Individual: .zip (project files) and .pdf (technical report)
  • Group: .zip (project files) and .pdf (reflective account + appendices)
• Submission Platform: Blackboard (Assessment & Submission Area)

---

Learning Outcomes (LOs) Assessed

• Individual Component: LO1, LO2, LO5
• Group Component: LO1, LO2, LO3, LO4, LO5

---

Assessment Overview

You will develop an IoT-based microservices application to monitor water quality in the Tyne River. The project involves:

• Real-time CSV data processing
• Safety flag checks against WHO limits
• Front-end dashboard for data visualisation

---

Individual Component (60%)

Functional Requirements

You will develop:

1. Monitoring Microservice:
   • Reads CSV records every 30 seconds.
   • Stores each record (with UUID & timestamp) in a permanent database.
2. Water Quality Microservice:
   • Reads one record at a time from the Monitoring Microservice.
   • Calculates Total Dissolved Solids: bashCopyEditTDS = CUSOL1 (mg/l) + (CUSOL2 + FESOL1 + ZNSOL) converted from µg/l to mg/l
   • Checks each parameter against WHO limits and sets a Green/Red flag.
   • Flags are not stored.
3. Testing Project:
   • Unit tests for both microservices.
4. Data Folder:
   • Includes the permanent database and sample data records.

WHO Drinking Water Limits

Parameter	WHO Limit
Turbidity	5 NTU
pH	6.5 – 8.5
Alkalinity	500 mg/l
Conductivity	2000 µS/cm
Nitrite	< 1 mg/l
Total Dissolved Solids	1000 mg/l

Technical Requirements

• Language: Java
• Architecture: API Gateway to manage microservices communication
• Database: MongoDB / SQLite (Each microservice can have its own DB)
• No external APIs or datasets (use only provided CSV)
• Error/Exception handling
• RESTful API documentation
• Object-Oriented Design, proper structuring & code styling

---

Individual Technical Documentation (PDF Report)

Sections to include:

1. Architecture Diagram – Interactions between microservices
2. Database Schema – Tables, fields, and relationships
3. Class Diagram – Classes, interfaces, methods, attributes
4. API Documentation – Endpoints, HTTP methods, requests/responses, error codes
5. Critical Evaluation (~500 words) – What went well, what could improve
6. References – Any libraries, tools, or documentation used

---

Group Component (40%)

Functional Requirements

1. Modular Front-End Web App:
   • Each member builds a module that consumes their microservice.
   • UI should show:
     • Latest safety flags per river (live updates).
     • Monthly averages of all parameters per river and overall.
2. User Authentication:
   • Java-based auth system
   • Features: Create/Delete Users, Change Password (Encrypted)
   • In-memory database only
3. Technical Details:
   • Front-End: React
   • Back-End: Java
   • RESTful communication
   • Modular design
   • Error handling & code documentation
   • No data stored for flags or averages

Quality Standards

• Object-Oriented & Modular Structure
• Use of functions & versioning
• No third-party design templates
• Clean, well-documented code

---

Group Reflective Account (PDF Report)

Includes:

1. Reflection on Developed Solution:
   • Social, Ethical, Security Concerns (~200 words)
   • Critical Evaluation (~200 words)
2. Agile Development Reflection:
   • Agile Method (~200 words)
   • Agile Iterations (~200 words)
3. Personal Reflections:
   • 400 words per student on working in Agile, learning outcomes, and skill development
4. Appendices:
   • Appendix 1: Project Plan (Sprints, Tasks, Assignments)
   • Appendix 2: Logbook (Meetings, Notes, Progress)
   • Appendix 3: Peer Assessment Forms (Signed by all group members)

---

Group Demonstration

• 20-minute live demo covering:
  • Each member’s contribution
  • Solution architecture & implementation
  • Use of Agile and challenges faced
• Q&A on Agile process
• Recording via Panopto (available on Blackboard)
• Equity of Contribution
  Marks will be adjusted to reflect each student’s performance. This ensures:
  ‘Free riders’ do not benefit unfairly.
  High-contributing members are appropriately rewarded.
  Assessment of Contribution will be based on:
  Evidence from the Team Logbook
  Peer Assessment Forms
  Refer to the Group Work Assessments Policy for further details.
  
  Technical Documentation & Reflective Account Requirements
  1. Word Count
  Word count applies to main content only (excludes title page, ToC, references, appendices, figures, tables).
  Declare word count clearly using the provided template.
  Penalty:
  No penalty if under word limit or up to 10% over.
  If over 10%, marker will stop reading at the judged point.
  Refer to the Word Limit Policy.
  
  2. Referencing
  Use Harvard Format (as per Cite Them Right, Pears & Shields, 2008).
  Cite all sources clearly and accurately in-text.
  Include an alphabetical reference list at the end.
  Use reliable academic and industry sources (no Wikipedia or Generative AI references).
  Extensive paraphrasing or quoting should be avoided unless justified.
  Reflect original thinking—not just summarised sources.
  
  3. Document Presentation
  Submit using the provided templates.
  Include full student/group details on the first page.
  Maintain a clear structure using headings, subheadings, and paragraphs.
  Diagrams and figures must be numbered, labelled, and legible.
  Use academic tone:
  Avoid informal language, slang, emotional expressions.
  Technical report: use passive voice (e.g., “The module was tested…”).
  Reflective account: personal tone is acceptable (e.g., “I encountered issues…”).
  Ensure correct spelling, grammar, and style consistency.
  Explain all technical jargon for non-expert readers.
  
  Important Notes
  All reports will be checked for plagiarism and use of Generative AI.
  Generative AI is not permitted for writing technical documentation or reflective accounts.
  
  Peer Assessment Criteria
  Criteria
  
  Demonstration of relevant skills and knowledge
  
  Attendance at group activities
  
  Contribution to group activities
  
  Contribution to agreed tasks outside meetings
  
  Quality of work on agreed tasks
  
  Conflict resolution and decision-making
  
  Trust, support, and respect
  
  Listening and interpretation skills
  
  Generating and promoting own ideas
  
  Using suggestions from others
  
  Scores: Unsatisfactory, Poor, Satisfactory, Good, Excellent, Outstanding
  Justification: To be written in rationale column.
  
  Assessment Regulations
  Late Submission Penalties
  Delay
  Penalty
  ≤ 24 hours late
  -10% from total possible marks
  > 24 hours late
  Mark = 0
  Refer to Late Submission of Work and Extension Requests Policy.
  
  Academic Misconduct
  Plagiarism, collusion, or using paid help is strictly prohibited.
  Use of developer tools like GitHub Copilot is allowed with acknowledgment.
  Human-in-the-loop AI tools are not allowed.
  Refer to Academic Misconduct Policy.
  
  Opportunities for Feedback
  Formative feedback is available:
  Upon request
  During labs and office hours
  Through formative assessment tasks
  Summative feedback will be returned within 20 working days after submission.
  
  Submission Rules
  Work on the individual component alone (no sharing with group before submission).
  Use individual work as-is for the group project (document any changes and version APIs).
  If a component is unusable due to poor quality or effort, inequity of contribution will be applied.
  Missing logbooks or peer assessment forms → Group mark capped at 60%.
  Missing group demo without approved reason → Mark capped at 60%.
  Wrong file format, missing components, or not using templates → Mark = 0.
  
  Marking Scheme
  Individual Component (60%) – 100 Points
  Category
  Points
  Microservices Development
  82
  – Functionalities
  34 (Monitoring MS, Water Quality MS, Unit Testing)
  – Technical Requirements
  33 (API Gateway, DB, Error handling, Docs)
  – Quality Practices
  15 (Structure, OOP, Style)
  Technical Documentation
  18
  – Contents
  14 (Arch diagram, DB schema, Class diagram, API docs, Evaluation)
  – Quality
  4 (Presentation, References)
  
  Group Component (40%) – 100 Points
  Category
  Points
  Application Development
  58
  – Functionalities
  32 (Auth system, Dashboard, Data view)
  – Technical Requirements
  18 (UI modules, REST API, In-memory DB, Docs)
  – Quality Practices
  8 (Structure, OOP, Style)
  Reflective Account
  42
  – Contents
  18 (Solution reflection, Agile, Project Plan, Logbook)
  – Quality
  4 (Presentation, References)
  – Personal Reflection
  10 (400 words per member)
  – Group Demonstration
  10
  
  Marking Criteria – General Guidelines
  Grade
  Description
  0–29% (Fail)
  Lacks microservices, structure, or required functionalities. Heavy reliance on copy-paste code.
  30–39% (Fail)
  Basic awareness but major omissions. Poor structure and clarity.
  40–49% (Pass)
  Barely sufficient. Some technical requirements met. Mostly descriptive.
  50–59% (Pass)
  Functional and technically adequate. Minor issues. Good referencing.
  60–69% (Merit)
  Independent thinking. Strong functionality and structure. Mostly secure.
  70–85% (Distinction)
  Excellent implementation beyond requirements. Secure, modular, well-documented code.
  86–100% (Outstanding)
  Exceptional depth. Innovative design and execution. Exceeds expectations significantly.