Sprint 3: Building a Proof of Concept - Assessment Outline

Value: 20% of the Course Mark

Due: Monday 4th April (Week 8), 1pm

1. Task

In this sprint, you will be expected to:

1. Undertake the requirements engineering process for an application which uses the Invoice API ecosystem and design a usable product;

2. Update your software architecture design to incorporate the full stack of your application, and model user interactions with the system;

3. Plan for the completion of work;

4. Continue developing and maintaining your service API;

5. Design and develop a frontend for your application;

6. Develop an MVP of your application, using your API and other groups' APIs; and

7. Prepare a “Shark Tank” pitch of your proof of concept for stakeholders.

2. Overview

We are now moving into Phase 2 of the project.

3. Requirements Engineering

You will need to determine the specification for an application which utilises one or more of the service APIs to provide value to a relevant user. It’s important that you spend time at the beginning thinking about the following:

1. What problem are we solving?

2. Who is our target audience / consumer base?

3. What value are we providing to users? How are we improving the quality of their jobs / lives? Why should they pay for or use our product?

As part of this process you may wish to develop a series of Use Cases, User Stories and Acceptance Criteria that help you create a product design that is user-centric. Since this is a course about technical design rather than product design we will not assess you on your written requirements engineering. We will instead assess the business value of your proposed application via your pitch.

Document your requirements engineering inside a new Confluence page called Application - Requirements

4. Software Architecture

Create a Software Architecture Design for your application. You will need to incorporate the following layers into your design:

• Deployment Layer

• Interface Layer

• Services Layer - this can incorporate your API, other teams' APIs and any third-party APIs you use.

You may decide as a team to include an intermediary API that acts as a hub / controller to liaise between the other APIs and your frontend. If you choose to do this you will need to design the relevant layers and justify your decisions.

Document your design inside a new Confluence page called Application - Architecture.

5. System Modelling

Pick three of your Use Cases and create a Sequence Diagram for each case. A sequence diagrams models the end-to-end interactions between a user and a system. In each diagram, you will need to model optimal, optional and exceptional flows of interaction.

Place your sequence diagrams inside a new Confluence page called Modelling.

6. API Lifecycle

You have completed an MVP of your allocated service - but that’s no reason to stop there. Continue expanding and improving your API based on any feedback from your mentor, features that weren’t finished in Sprint 2, and anything else you want to add.

Any deployed updates to your API should be reflected in your documentation.

In this section you will be marked on the improvements you make, and your mark can increase based on how many other groups use your API.

Submit this form with a link to your Swagger documentation so that other groups can view and use your API.

You can view links to all groups' documentation here on the Service APIs page.

Place any relevant new material inside a new Confluence page called API Lifecycle.

In this Confluence page, you must also clearly provide the aliases (from the Service APIs page) of all other groups' APIs that you use and link to their documentation.

6.1 Versioning & Backwards Compatibility

Someone (perhaps another group!) may have a dependency on a particular version of a route of your API - and if you change that route in a way that will affect the interface or external behaviour, then this dependency may cause problems for the said API client. Given this, backwards compatibility is a non-functional requirement of your APIs.

Any routes which have external updated behaviour should be suffixed with /v2 and the original version of the route should still be available. All of this should be documented in your updated Swagger.

7. Frontend

As part of this Sprint you are expected to develop a prototype web-based frontend for the interface layer of your application (connected to your services). You will first, based on your system modelling and use cases, need to develop a User Interface Design that outlines what your website will look like.

We will not be marking your UI Designs - we will only be assessing the proof of concept your present in your pitch. However, you may wish to consider writing a few low-fidelity UI designs (wireframes/sketches) to begin with, and then a higher-fidelity one in a tool such as Lucidchart or Figma.

You are not expected to have a complete web application at this point - it is simply a proof of concept.

Document your UI designs and any relevant design decisions in a Confluence page called Frontend.

7.1 Code Quality and Design

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 in both your frontend and backend. 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.

7.2 Continuous Integration & Testing

You should setup CI to check that your frontend builds correctly. We do not require that you have tests for your frontend, though if you want to go the extra mile this is something to explore.

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

8. Project Management & Communications

8.1 Scrum Communications

All team communications are as they were in Sprints 1 and 2;

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 requirements engineering meeting(s);

• 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 your Communications Confluence page, document any reasoning and screenshots of communications outside MS Teams.

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

9. Shark Tank

During your mentoring time slot in Week 8, you will deliver a 10 minute presentation to your class and two assessors, including:

• The concept of your application, what it is and how it provides business value to users;

• An overview of your Software Architecture Design and a discussion of some of the technical challenges and constraints you faced in developing the prototype; and

• A demonstration of your working prototype, deployed on the cloud.

Your task is to convince your assessors - who are “stakeholders” wanting to make an investment - that your product is worth investing into (think Shark Tank).

The 10 minute presentation will be followed by 3 minutes of questions from the assessors and audience.

You will be assessed on your presentation skills, the business value of your proposed product and how convincing your prototype application is in delivering value.

All team members need to be a part of the presentation in some way.

Teams should be present for all other groups' presentations in their class. If you cannot attend part or any of the class, please email your mentor prior to the presentations.

9.1 Presentation Skills

You will be assessed on the following presentation skills for your pitch:

• Engagement, presence and clarity of presentation;

• Eye contact, body language and voice modulation;

• Use of visual aids (e.g. slides) to increase engagement;

• Smoothness of prototype demonstration; and

• Keeping to time. Groups that go over 10 minutes or under 8 minutes will be marked down.

We recommend you rehearse your presentation beforehand.

10. Marking Criteria

11. Submission

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

For this sprint, we will take the state of your Jira board, Confluence space and Git Repository at the deadline as your submission. You do not need to run any submission commands.

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.