Versions Compared

Version Old Version 6 New Version Current
Changes made by

Tay Leung

Garvi Poudyal

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Software Quality - testing - pylint / pytest percentage , style - docstrings , testing practices , continuous integration and testing - how it is being run and hosted , what peripheral systems are being hosted, decision making and reasoning , continuous deployment

Front End Design - UX/UI, Figma , decision making process and reasoning , wireframes, user testing , use cases , system modelling , sketches

Project Planning, refer to table - include the kanban method , scrums, agile etc etc, organise priority , table of comparison, deciosn making process and reasoning, organised GIT commits, git practices

Team Roles - Strengths + weaknesses , team leader/ scrum / product owner / delivery manager , decision making process and reasoning

Topic

Requirements + constraints analysis (15%)

Requirements Analysis

  • Are the functional and non

functional (security, performance) , correct user , user stories and acceptance criteria , logically group features , what competition looks like ……. Constraints -Assumptions , Technical Challenges

System design

Software Architecture Design(frameworks - comparison table , multiple comparisons, decision making process and reasoning), Sytem modelling, API design, api lifecycle

Breadth and Depth of Implementation

Project Management and Communications

Report Structure

abstract, appendix , conclusion , no word limit , cover page , problem statement, Formatting, Future improvements, reflections

  • -functional requirements designed with users in mind?

  • Are the requirements thoughtful and insightful?

  • Are the requirements conveyed via user stories, acceptance criteria or “done”?

Constraints Analysis

  • Report provides a comprehensive discussion on constraints that affected the project, including but not limited to:

    • Time

    • Budget

    • Coding capability

    • Limited spec.

System design (35%)

Software Architecture Design

  • Are all layers of the software architecture design thoughtfully chosen?

  • Is the decision making process for each layer shown, with multiple options?

API design

  • Do the endpoints make sense? (reflect the requirements)

    • Are they easily understood?

    • Do the features and explanations make sense?

    • Do they achieve the initial aim?

Sytem modelling

  • Is the system modelled well via UMLs?

  • Does the system modelling clearly show the flow of data/control?

API lifecycle

  • Frontend too (what changed for the actual product)

  • Consider the feedback from shark tank - to show what was improved

  • Was the API updated during later sprints?

    • Were the updates reasonable?

    • Was original functionality kept?

Breadth and Depth of Implementation (35%)

Software Quality

  • Is there a suite of tests which gives a sufficient coverage score?

  • Are the tests well designed and thought out?

  • Have tests been written at multiple levels of abstraction as specified?

  • Is the code of high quality, and does it follow software engineering practises?

  • Is there continuous integration?

  • Is the code well documented?

Deployment

  • Is the service available and functional for anyone to use on the internet?

  • Does the deployment satisfy user requirements?

Front End Design

  • Does the front-end UX/UI design satisfy the user requirements?

  • Is there good use of prototyping both low-fidelity and high-fidelity sketches on tools such as Figma or Lucidchart? 

  • Have UX/UI been clearly documented with relevant design decisions?

  • Does Front end code follow Software Engineering design principles?

Project Management and Communications (10%)

  • Has there been consistent agile communications made throughout the term (standups, sprint retrospective, sprint planning)?

  • Does the report provide a comprehensive discussion of the agile communications methods used (including pros and cons)?

  • Have team roles been clearly assigned, providing reasons based on 

    • Strengths 

    • Weaknesses 

    • Interests 

    • Goals

  • Have boards, issues and git practises been used appropriately?

Report Structure (5%)

  • Report is free from all spelling and grammar errors  

  • Report is  professional and well written 

  • Does the report tell a story?

  • Does the report use  headings and sections to order a well formatted and readable report.

  • All figures, graphs, tables are correctly displayed, contain titles and captions.