...
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
What is this Sprint aiming to achieve? It’s time to actualise your designs into life. In Sprint 2, you’ll be building an MVP of your microservice/API. The learning outcomes of this Sprint can be broken down into three major pillars:
Perfect is the enemy of good |
. Pick the most important things and prioritise them!1.
...
Tasks 🕶️
In this sprint, you will be expected to:
Revise your requirements list to include a series of non-functional requirements;
Finalise your Software Architecture Design and API Design;
Create a data model for your service;
Implement a first version of the service (MVP) using test-driven development; and
Deploy the service on the internet
There are 3 aspects that need to be taken into account.
2. Implementation and Deployment
2.1 Development of the Service 🛠️
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.
You need to ensure that your repository, which you and your team will use to host all your source code, is available to your tutor as maintainer to access. 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.2 Testing Practices
As part of implementing the service, you will need to use test-driven development.
The layers of abstraction at which you write tests are up to you for the most part, however we require that you have tests which:
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.3 Deployment 🚀
Students have the freedom to select any deployment provider of their choice that suit their project needs and preferences.
Update your Software Architecture diagram as needed.
3. Software Requirements and Design Quality
3.1 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:
Security. Access to the service functionality of the API must be protected using an appropriate series of authentication and authorisation mechanisms. Document any relevant content inside a confluence page called Security.
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.2 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 updated design. There are some example formats 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.
...
3.3. 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.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 can create your repository, which you and your team will use to host all your source code and set up your tutor as maintainer to access.
...
3
...
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
...
.
...
4
...
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):
Automated running of your test suite;
Code linting;
Coverage checking;
Build checking, if your service is written in compiled / built code; and
(Optionally) Complexity checking, if such support exists for your language.
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.
The layers of abstraction at which you write tests are up to you for the most part, however we require that you have tests which:
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.
...
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 🚀
Students have the freedom to select any deployment provider of their choice that suit their project needs and preferences.
Update your Software Architecture diagram as needed.
...
4. Project Management & Communications
...
...
4.1 Scrum Communications
All team communications are as they were in Sprint 1;
...
Inside a Confluence page called Communications, document any screenshots of communications outside MS Teams.
...
4.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;
...
;
4.3 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. Marking Criteria 
Criteria | Description |
|---|---|
Breadth & Depth of Implementation and Deployment (35%40%) | 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:
|
Software Requirements and Design & Architecture Quality (30%40%) |
|
Deployment (5%) |
|
Project Management & Communications (10%20%) |
|
...
6. Submission ⬆️
Submission Requirements
Add a link to your Git repository inside your online documentation website (Confluence page).
The Confluence page should be named "Codebase" and submitted via Moodle Sprint 2 submission.
Ensure that your tutor has full access to the repository and documentation space.
...
Applications for Special Consideration and ELS assessment accomodations will not include extensions as this is a group project with no scope for extending deadlines. The course authority will determine an appropriate adjustment in cases where a Special Consideration request is approved or a student has an equitable learning plan. Students in either of these positions should email se2021@cse.unsw.edu.au.
...
7. Plagiarism 
The work you and your group submit must be your own work.
...