Page Comparison

...

...

Value: 20% of the Course Mark

Due: Monday 14th March (Week 5), 1pm

1. Task

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

Based on any feedback from your mentor on Sprint 1, along with any other changes you as a team wish to make, update your Software Architecture design as needed. You will need to produce a diagram of your finalised design. The format is up to you, there are some examples provided in lectures; it simply needs to highlight the different layers at a high level, and roughly how they connect/interact with one another.

...

Update your Architecture and Interface pages as necessary, including providing a link or render of your Swagger documentation.

4. Data Modelling

In Sprint 1 you designed your service at a high level - choosing the components of the stack. Now, it is time to zoom in and focus on the initial design of the data model.

...

The documentation will need to show how the data is stored (at the relevant level of abstraction), how it relates to one another and it should be clear how the application and persistence layers are interacting.

5. Development of the Service

5.1 General

Using the tickets you have specified in Sprint 1, build an MVP of the service. It does not need to be perfect - you may find that there is more than you as a team can complete in the 2 weeks. You may however find that you finish ahead of time and are able to complete more - this is fine as well. The different service categories will have different difficulties. If you find you and your team have time left, you may update your Requirements page and implement extra features of the API which provide value to the API client.

5.2 Source and Version Control

You will need to create a Git repository for your codebase using your chosen platform.

...

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:

• DRY (Don’t Repeat Yourself);

• KISS (Keep it Simple Stupid);

• Using abstractions appropriately, including external libraries and modules; and

• Adhering to language-specific conventions (e.g. “Pythonic”);

• Correct casing of variable, function and class names;

• Meaningful variable and function names;

• Readability of code and use of whitespace; and

• Modularisation and use of helper functions where needed.

5.4 Continuous Integration

You should setup an automated Continuous Integration system in your repository. The CI will need to include (but does by no means have to be limited to):

...

The CI should run on all Merge Requests / Pull Requests into the main branch of the repository.

5.5 Testing Practices

As part of implementing the service, you will need to use test-driven development.

...

• System tests which test the API endpoints;

• Unit tests which test individual parts of the system working in isolation; and

• Your tests provide over 85% coverage of the code in the repository. You are welcome to change this requirement as you see fit, however it must be justified.

5.6 Git Practices

You will be assessed on the following Git practices for development:

• Commit messages are detailed and specific;

• Avoid committing large chunks of code;

• All merges into main/master are done via merge requests;

• Code reviews are conducted, with evidence of comments in the MR/PR and approval by at least one other team member;

• In most cases, One ticket = One branch = One merge request into main/master.

5.7 Assumptions

As you design and implement the service, you will undoubtedly realise ambiguity in the specification and will need to make a series of assumptions. Document these in a Confluence page called Assumptions.

6. Deployment

Using your chosen deployment provider, make your service publicly available on the internet.

...

If possible, you should also need to setup an automated deployment - where a push to your main branch automatically deploys to the chosen provider.

7. Project Management & Communications

7.1 Scrum Communications

All team communications are as they were in Sprint 1;

...

Inside a Confluence page called Communications, document any reasoning and screenshots of communications outside MS Teams.

7.2 Task Tracking & Management

The Jira task board is your point of reference for managing the project. You will be marked on:

• 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

9. Submission

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

...