Content Comparison

Software Design and Architecture (+ API Design)

• Able to provide functionality, that is able to show all of the services that we offer such as creating, rendering and sending

• Researched into a number of different platforms

N/A

• Continue doing this for now, works well

Data Modelling

• Broke the application into smaller processes such as creating an account, creating invoice and sending the invoice.

• Show relationship between the different layers and flow of information

• Since sprint 2 we have stuck to a consistent DB structure, which has helped in planning our design and constructing a solution

• Wide range of actions and use cases. Can be quite complicated to model some of the more complex and larger use cases

• Able to model some of the more complex use cases, such as creating an account, creating invoice, rendering in and sending it as on sequence diagram to show the flow between the different APIs instead of them as separate diagrams

• Simplify and break down tasks

• Plan out diagrams before starting

Software Quality / Development of the Service

• Implemented coverage and were able to get higher coverage with more tests

• Used pylint and pytests for all backend/api code to check quality

• We had coverage working earlier in the sprint

• Setup CI for frontend code

Deployment

• All services hosted through Heroku

• Able to setup CD and have consistent up time

• Able to integrate multiple APIs into one url instead of seperate url for each part

• Look into integrating all the different systems currenlty currently being run into one

Project Management + Communication

• Consistent updates on progress from team

• Good use of sprint planning - to delegate tasks

• Consistent meetings - when needed which included free workspace times → + group programming

• Good use of meeting times, to discuss issues and any group related tasks

• Improvement on giving prior notice if unable to make meetings or work on things

• Similarly from Sprint 2, greater emphasis on Asynchronous standups, for members to update the team on their progress (improved from Sprint 2)

• Creating tickets for any needed documentation, so that it is clear who is working on what and if they have been completed

• Better use of stand ups. Often forgotten on day they were supposed to be done.

• Members were able to join at the start of the meeting time

• Not everyone could always make the meetings due to unexpected plans (not noted in the sprint planning) coming up - and us moving our meeting times.

• Many issues that had been planned during Sprint 1 ~ for Sprint 2, weren't accounted for. A lot more issues needed to be added onto Jira (continual issue for sprint 3)

• Reminders to complete stand ups on day they are due

• When sprint planning, adding tickets for any documentation that is required

• Having meeting times where members are awake and able to join at the agreed time. Only suggesting times that you know you'll be able to wake up for, so that there is no wasted time.

Front End

• Great slide deck - very visual

• Created a wireframe - for both high fidelity and actual prototype design (early on) allowing us to start the Front End code early in the sprint.

• Able to use tools such as Figma to prototype our product - good for accuracy when it comes to creating the front end as we know what the final needs to look like

• Created story line for why our product is investable

• Were able to work around the different challenges of combining multiple APIs

• Members were more familiar with front end coding languages - required a lot of upskilling with little time

• Do more individual research - to see how we can make additional features for Sprint 4.