Versions Compared

Key

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

Value: 20% of the Course Mark

...

In this sprint, you will be expected to:

  1. Revise your requirements list to include a series of non-functional requirements;

  2. Finalise your Software Architecture Design and API Design;

  3. Create a data model for your service;

  4. Implement a first version of the service (MVP) using test-driven development; and

  5. Deploy the service on the internet.

2. Non-Functional Requirements

In addition to the requirements you analysed in Sprint 1 from the initial service specification, you can start documenting your thoughts about the following considerations:

  1. Security. Your security considerations should include, but are not limited to the following:

    • Authenticity - Access to the service functionality of the API must be protected using an appropriate series of authentication and authorisation mechanisms;

    • Accountability - all activity on the API (calls to endpoints) should be tracked and kept in a log.

    • The infrastructure on which the service is deployed needs to be secure (physically and electronically, as much as possible).

    • Document any relevant content inside a confluence page called Security.

  2. Performance. The API endpoints should take a minimal amount of time to complete. In most cases this will be relatively straightforward. In some, where computations are more complex, you will need to spend time designing your algorithm with pseudocode to determine the algorithmic complexity and reduce it as much as possible. Document any relevant content inside a confluence page called Performance.

3. Software Architecture & API Design

...

All team members must be added. You will also need to add your mentor (who will provide you with their username for the platform) and se2021-bot as administrators of the repository.

You are required to use Git to keep track of your code.

All students are required to fill out this declaration form regarding academic integrity.

5.3 Code Quality

You will be marked on the quality of your code at a module / class / file / package level as well as the quality of the code itself. You should make logical design decisions, write robust code and adhere to Software Engineering design principles, including but not limited to the following:

...

  • The board shows the truth of your team’s progress;

  • Tasks are updated, added to and adjusted as necessary as the project progresses;

  • Tasks are updated across the kanban columns; and

  • Tasks are completed according to their assigned priorities.

8. Marking Criteria

Criteria

Description

Breadth & Depth of Implementation (35%)

This is a qualitative mark that your mentor will give based on how much of your service you have implemented, and the quality of what you have implemented. Considerations that are taken into account:

  • Complexity of functionality

  • Robustness of functionality (whether it is working)

Software Design & Architecture (30%)

  • Is the stack well designed and justified, and have any changes from Sprint 1 been documented and justified?

  • Have the non-functional requirements been accommodated and designed for?

  • Has a data model been produced which is accurate and demonstrates thoughtful planning?

  • Have the different layers been written and abstracted appropriately in the code?

  • Does the API design provide a near-complete solution to the specified requirements?

  • Does the API provide ability to create, read, list, update and delete data in the service?

  • Have all required fields been included for each endpoint?

  • Are the endpoint descriptions succinct and understandable?

  • Is the interface well formatted and readable?

Software Quality (20%)

  • 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?

  • Do the tests cover a wide range of conceptual cases?

  • Has CI been setup to automatically check code in the repo?

  • Is the code well written and styled (See Section 5.3)

Deployment (5%)

  • Has the service been deployed on a platform?

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

Project Management & Communications (10%)

  • Are meeting minutes well laid-out, detailed and insightful?

  • Has the team been using a platform for regular communication?

  • Has the team undertaken Agile communications? (standups, sprint planning, sprint retrospective)

  • Has the Jira board been used correctly (See Section 7.2)

  • Have git commits and merge requests been used appropriately?

9. Submission

Place a link to your repository inside a Confluence page called Codebase.

...