Project Management & Communications

• Get an MVP!!!

• Try to do extra requirements (security, performance, etc.)

• None

Requirements

Tomorrow (3rd March)

• N/A

Updated requirements for security and performance

User stories created

MVP

End of the Week 1 (6th March)

• Code not working

• Need to run pytests

• Limited skill set to write and design our database

-Send an email by the end of the week

Write and design our database

Second Week (8th March)

Have relevant diagrams finalised and refined

Make our ER diagram for the database

by Friday (4th March)

• Not every member is familiar with ER diagrams - refer to lectures

Consider connection of user, calls, email address, token, username, password

API call - time called, name, user to, caller authenticated

Design our interface,

by Friday (4th March)

• Continue progress from Sprint 1

Logical reasoning for our designed intersperse - finalised methods of persistence, deployment, server API

• No holidays will hinder capacity

• Weekly labs, quizzes and assignments due in the next 2 weeks

•  

Nothing coming up

• Away for weekend (5-6/3/2022)

Assignment for Operating Systems 11/3/22 RIP

Industry agreement making + emailing (dead)

Assignments + Weekly labs, quizzes and assignments due in the following weeks

Open

Confirmed meetings : 10:30am Monday (Virtual)

9pm Thursday (Virtual)

1-4pm Tuesday (In-person)

Software Design and Architecture (+ API Design)

• Review of feedback from Sprint 1 → able to update the Stack Architecture (comparative table for application and persistence methods)

• Greater scope for our reasoning ~ many. decisions were based on group familiarity and the time capacity we had in the need to learn new code

• Current MVP provides basic functionatlity

• Add home page that describes functions of the API

Data Modelling

• Basic design of DB kept through sprint

• SQLalchemy worked well for accessing DB

• Hosting on Heroku for Postgres worked well

• Further planning would enable initial design to be stuck to better

• Should be no further issues as now that DB is setup and issues with our design have been found it should be consistent

Software Quality / Development of the Service

• Each function is short and serves one purpose.

• Each function has an appropriate name which is clear about what it is meant to do

• With functions split over multiple functions, it is easy to group them together by what they achieve.

• If due dates were added for functions that were required by others. So that each member is clear on when things are needed to be complete

• CI was implemented earlier on in the sprint.

• Having due dates on tickets and having meetings and at each meeting reminding everyone when things are due.

• Greater emapshasis and logical reasoning on Priority of each task so that members can provide help if needed

Deployment

• Heroku deployment was easy

• Using environment variables for secrets was easy and secure

• Heroku DB integration was nice as it sends DB login straight to deployed service

• Was able to detect when on Heroku and only use production DB then, using sqllite database for deployment and testing.

• Haven’t been able to add members to Heroku, so only Joshua has access to account to manage deployment

• Add other members as collaborators so they can manage deployment

Project Management + Communication

Open

WWW communication in sprint 1

• 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

• What went well (from Sprint 1) was well kept (refer to picture on the right)

• Improvement on setting clear goals and actionable for meetings

• From Sprint Retrospective Sprint 1 Ways Forward : “Continue same template + consistency of how often meeting minutes and stand ups occurred for iteration 2” Generally done well.

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

• Similarly from Sprint 1, greater emphasis on Asynchronous standups, for members to update the team on their progress

• From Sprint Retrospective Sprint 1 Ways Forward : “Create a list of questions during every meeting, that can be brought up during the physical tutor time slot” Questions weren’t brought up as often. due to Sydney weather, half the team could not attend the physical tut

• 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

• Need to re-evaluate our availabilities for Sprint 3 + 4

• Use the first 5 minutes of each meeting to CLEARLY update the team in addition to updating via messages / somewhere throughout the meeting. (set aside specific time)

• Consistent group evaluation on the Issues created - Last minute → recognised that “emails sent to multiple recipients” didnt need to be completed, hence was removed from