Sprint 4: From Prototype to Product - Assessment Outline

Value: 30% of the Course Mark

Sprint Due: Tuesday 19th April (Week 10), 10am

Final Report Due: Friday 22nd April (Week 10), 9pm

1. Task

In this sprint, you will be expected to:

  1. Finalise all elements of your design for your Service API and Application, and compile a written report;

  2. Continue developing and maintaining your Service API;

  3. Continue developing and maintaining your Application, moving it from a proof of concept towards a usable product; and

  4. Prepare a follow-up “Shark Tank” pitch of your product for stakeholders.

2. Final Design Report

Your final report should essentially be a compilation of all of your documentation you have completed throughout the project, for both your Service API and Application. Rather than us specifying what exactly should be in your report, however, your task is to decide on what is important and what you should include.

2.1 Report Specification & Marking Criteria

Before writing the report, you must first write a report specification - think of it as what would be here if we told you what you needed to include. In addition, you must also devise a report marking criteria. It should include:

  • Weightings for each section of the report; and

  • A definition of what good, or done looks like. The exact format of this is up to you, you may wish to look at marking criteria in this course or other rubrics;

We will assess your specification and marking criteria itself, and then we will mark your report using your own marking criteria. Your final report mark will be a mathematical average of those two results (see Section 7).

You will need to write your marking criteria before writing the report, and have the marking criteria approved by your mentor. This is, in effect test-driven development, but for something that’s non-technical instead of technical.

2.2 Documentation

In this Sprint, all your primary documentation marking will be done via your report - so you are welcome to use Confluence as much as you like throughout, however for submission you will need to ensure everything you wish to be directly marked is in the report. You can link Confluence pages as supporting documentation in the report as well.

3. API Lifecycle

Continue to iterate, expand upon and improve your Service API. Any deployed updates to your API should be reflected in your documentation.

As per Sprint 3 , your mark in this section 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 if you have not already.

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

Your API should use versioning and remain backwards-compatible.

4. Application Lifecycle

As you did with your Service API in the previous sprint, you are expected to build and improve on your Application based on Sprint 3 feedback, and move the application from a simple prototype towards a polished product.

All previous requirements apply with regards to development practices, continuous integration and code quality.

5. Project Management & Communications

5.1 Prioritisation & Planning

In this Sprint you have a lot of scope to focus on what you as a team believe is important - so it is vital that you spend some time deciding on what that is during your Sprint Planning Meeting. As with all your previous sprints, you will need to create tickets in the Jira backlog with Story Points and Priorities assigned - and you will need to justify these priorities based on your team’s vision.

Other than this, all project management assessment requirements are as they were for previous Sprints.

5.2 Communications

All communication requirements are as they were for previous sprints, except for the following:

  • The Sprint Retrospective meeting is instead a Project Retrospective, where you as a team reflect on the project in its entirety.

6. Shark Tank, Round 2

Your “stakeholders” (assessors) were impressed with your initial presentation and want to bring their own investors in on the idea, as well as see your progress since the previous demonstration.

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

  • A brief review of the concept of your application, what it is and how it provides business value to users;

  • A brief refresher on the Software Architecture Design, and highlighting any significant changes made since the previous presentation;

  • A discussion of technical challenges and constraints you faced in moving from a prototype to a product; and

  • A demonstration of your working product, deployed on the cloud - with an emphasis on the features completed in this Sprint.

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

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

7. Marking Criteria

Criteria

Description

Criteria

Description

Shark Tank (25%)

  • Is the concept of the application a convincing and an “investable” idea?

  • Does the application provide value to users?

  • Is the target audience clear and does the application meet their needs?

  • How well does the group present? (See Section 6.1)

  • Does the User Interface support the convincingness of the proposed product? Use of colour schemes, logical layout, accessibility.

  • Does it look nice and like a polished product that you'd want to use?

  • Has the product improved in quality since the previous demonstration?

  • Does the team demonstrate a convincing technical understanding of their engineering and decisions?

Final Design Report (30%)

Report Specification & Marking Criteria

  • Create a specification for the contents of the design report

  • Does the specification cover all of the areas relevant to the project and course learning outcomes?

  • Is the specification clear and concise?

  • Does the marking criteria provide a suitable definition of what good/done looks like?

  • Are the weightings on the marking criteria appropriate?

Report Contents

This will be assessed based on the marking criteria you develop.

Your overall mark for this section will be calculated using the formula:

= 2 * s * r / (s + r)

Where s is the mark for your specification and r is the mark for your report. This formula is known as a harmonic mean which you can read more about here.

Breadth & Depth of Implementation (30%)

This is a qualitative mark that your mentor will give based on the breadth and the quality of what you have implemented, for:

  • Your service; and

  • Your application.

Considerations that are taken into account:

  • Complexity of functionality

  • Robustness of functionality (whether it is working)

Your mark can increase by a factor depending on how many groups make use of your service.

Software Quality (10%)

  • Is there CI checking all parts of the application?

  • Is the code well written and styled?

  • Have any necessary improvements to the API code been made?

  • Have any necessary improvements to the frontend code been made?

Project Management & Communications (5%)

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

  • Have git commits and merge requests been used appropriately?

8. Submission

Your report should be contained in a PDF in a Confluence page called Final Report.

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.

In addition, one of your team members will need to run the following command to submit your final report.

You can submit your final report here at this page, or via command line on a CSE machine using the following command:

give se2021 final_report report.pdf

Make sure your file is named report.pdf.

The late penalty for the report submission is the standard UNSW late penalty of a 5% per day reduction of the maximum report mark. For example, if the report would receive an on-time mark of 7 / 10 and was submitted 3 days late the actual mark would be 5.5 / 10.

Late submissions for the other parts of the Sprint 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.