Value: 20% of the Course Mark

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

1. Tasks 🕶️

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

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:

1. 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.

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.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.

You will need to decide on your API Design, and complete the API Documentation using Swagger.

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.

How you do this will depend on your chosen stack:

• If you are using a relational database, you will need to produce an Entity Relationship Diagram;

• If you are using Java / C# (or a similar Object-Oriented Programming framework) for the application layer, you will need to produce a UML Class Diagram;

• If you are using a NoSQL database, you will need to produce the format in which your data is stored.

If your technical design doesn’t fit into any of these cases, try to determine what the corresponding data model should look like, and check with your mentor if you are on the right track.

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.

3.4 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.

4. Project Management & Communications

4.1 Scrum Communications

All team communications are as they were in Sprint 1;

As part of this sprint you will need to demonstrate your ability to communicate and work as a team. You will need to have:

• A sprint planning meeting;

• Regular standups, either synchronous or asynchronous (at least 3 a week); and

• A sprint retrospective meeting.

You will need to take minutes for your meetings and record these on Confluence. Minutes should contain information on:

• Who was there;

• What was discussed; and

• Action items.

Meeting minutes should also be taken at project check-ins.

You are welcome to use whatever asynchronous communication platform you as a team choose (MS Teams, Slack, Facebook, Discord) - however your tutor will setup a MS Teams Channel for you to communicate in, and this is the only place we will look when marking your communication and resolving disputes.

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

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.

The grading tutor will assess the state of your Jira board, Confluence documentation space, and Git repository at the submission deadline.

Submission Process

• Only one team member (the Scrum Master) should submit the repository link on Moodle.

• If the Scrum Master is unable to submit, inform your tutor as soon as possible.

Late submissions will not be accepted.

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.

Students are permitted to use generative AI, provided they clearly disclose its use and seek confirmation from their mentor beforehand. This approach ensures transparency and responsible use of generative AI tools. 

Relevant scholarship authorities will be informed if students holding scholarships are involved in an incident of plagiarism or other misconduct.

You are welcome to seek help from other students taking the course, however all work you submit must be your own. The use of external contractors to complete the project or your part of the project is not permitted.

During your mentoring sessions, you mentor will be using the opportunity to interview you and ensure you are contributing to the project.