Student Shorts - COS-301/graduates GitHub Wiki
Documentation
Roles:
- Project Manager: Rayden Burger
- Business Analyst: Klara Meyer
- Testing: Kearon Foba
- API Engineer: Benjamin Osmers
- Data Engineer: Alex Küsel
- Services Engineer: Matthew Gotte
- Designer, UI Engineer, DevOp: Dylan Whiteford
Introduction
Our group’s feature is “Social Features such as Student Stories”. Thus, we will implement a feature that allows students to post videos or images to share with their fellow students. As the concept of “stories” is not an original one, successful existing implementations have been researched. YouTube Shorts, Instagram Stories and TikToks all function in the same way at their cores. Thus, the functionalities that make each of these platforms successful have been considered. There are multiple basic things that each of these platforms have in common. This includes an intuitive and simple interface, short attention-grabbing videos or images as well as navigation between content of different creators or different types of content. Thus, we will ensure that the above mentioned will apply to our implementation so that it is pleasant to use.
SRS Document for Student Shorts - Ruby.pdf
Functional requirements
- FR1: A Short can be uploaded as a video or an image.
- FR2: A person may upload multiple Shorts.
- FR3: A student can remove their own Short.
- FR4: Page for viewing all Shorts.
- FR5: Link from student profile displays all Shorts by the specific student.
- FR6: Report button so that a Short that students have reported can be reviewed.
- FR7: Be able to add tags to Shorts or edit existing tags.
- FR8: Stories can be searched by tags from Shorts explore page.
Use case diagrams
Non-functional requirements
- NFR1: The videos should have a maximum resolution / file size so that all videos can be loaded quickly.
- NFR2: Navigation between Shorts, student profiles and tags should be intuitive.
Acceptance Criteria
- AC1: Students must be able to upload a video story.
- AC2: Stories must be able to be viewed by other students.
The following should be implemented by next year’s students:
- A graduate should be able to delete Shorts that they have uploaded.
- A graduate should be able to edit existing Shorts’ tags.
- When a graduate is uploading a Short, there should be an interface that allows the graduate to overlay text, effects, stickers, etc. over their Shorts before posting.
- A graduate should be able to like a Short.
- More advanced algorithms for determining in which order Shorts are displayed on the explore page: for example, a combination of recency and popularity.
- Optional: graduates should be able to follow other graduates such that the followed graduates’ new Shorts are displayed first on the explore page.
Collaboration with other teams:
Throughout the sprint we were involved three main teams that associated with our system, namely Fortran(storage), PHP(admin console) and Pascal(Student profiles).
Components
Mr Rayden Burger u20424622 - PM
- Effectively managed the coordination and planning throughout the entire project.
- Managed the communication with all members in the team, mediated altercations and disagreements throughout teammates and found compromises.
- Communicated with other groups that related to the team’s feature.
- Built multiple organisational and productivity streams to manage efficiency of the team.
- Supported teammates throughout the timeline of the project.
Ms Klara Meyer u20428082 - BA
Sprint 1
- Researched the functionalities of successful existing implementations of “stories”.
- Formulated the functional requirement, non-functional requirements, as well as the acceptance criteria of our feature.
- Made a detailed document explaining how our feature should respond in all use cases.
- Created the use case diagrams of our feature.
- Discussed how the Wiki requirements should be done with the other the BA’s. (03/14/2022)
Sprint 2
- Created a detailed SRS document for our feature.
- Updated our feature's wiki such that it contains the most up to date and complete information regarding our feature.
- Compared our final product's test cases to my acceptance criteria in order to determine if our feature can be considered functional and signed off on the feature by creating a sign-off document.
Mr Kearon Foba u13312694 - Testing
Sprint 1
- Discussed the format and division of testing implementation for developers and testers (Meeting - 14/03/2022)
- Deliberated with other testers and discussed the standard specification for testing and test result documentation (Meeting - 21/03/2022)
- Agreed upon standard presentation of documentation
- Planned activities:
- Explain process of and direct developer in unit testing implementation
- Create test documentation
- Test Cases
- Test Execution Report
- Ensure the feature testing protocols are aligned with project
- Ensure feature testing complies with project testing to streamline testing with CI/CD once CI/CD is implemented
- Ensure tests cover edge cases
- Perform e2e (end-to-end) tests once all sub-features are implemented
- Perform integration tests once related features are implemented
- Ensure feature complies with all tests and can function within the environment of the project.
Sprint 2
- Reviewed team PRs to ensure CI compliance
- Wrote integration tests for API and DB; and API and front-end.
- Wrote E2E tests for feature
- Wrote Test Cases for above tests
- Performed UAT testing with Test Cases aligned to Functional Requirements
- Wrote Test Summary Report
- Assisted team wherever possible if PRs did not pass CI tests initially
- Ensured tests remained updated as code was amended
- Screenshots, documentation and links in PDF attached below.
Mr Benjamin Osmers u16068344 - API Engineer, Service Engineer, Data Engineer
Sprint 1
- Created shared library for API.
- Created the api/shared/services/prisma/data-access library in which a Prisma Service was implemented. This connects a Prisma Client to the database and can now be used by all teams.
- Created the library for our feature.
- Created an api/shorts/api/feature library in which the module and resolver for our feature was implemented. The resolver successfully injects a service which calls a mock api to fetch all user shorts in the database.
- Created an api/shorts/api/shared library in which an entity was created to represent a short.
- Created an api/shorts/service/feature library which contains a query, query handler, and shorts service. This injects the repository and queries the database to fetch all user shorts.
- Created an api/shorts/repository/data-access library which contains a repository which is used to communicate with the database.
- Committed all changes, made pull requests, which were successfully merged.
Sprint 2
- Took on the roles of API Engineer, Service Engineer, and Data Engineer
- As the data engineer I worked alongside fellow data engineer, Alex. We wrote the code for the repository layer which consisted of querying the database using Prisma client.
- As the Service Engineer I wrote commands, queries and their handlers. These actions are dispatched by the service class.
- As the API Engineer I wrote the code for the GraphQL Resolvers. I wrote resolvers for the Shorts. Short Reports, and Short Tags.
- Together, these three layers form the API and backend for our feature. Unit tests for each layer were also implemented by me.
- To aid our frontend engineers and future groups, I wrote documentation for our API. Each route for our API is documented with descriptions and sample GraphQL queries. As well as descriptions of each parameter, and what each query returns.
Mr Alex Küsel u19236183 - Data Engineer
Sprint 1
- Agreed with the standards for the database as discussed in the meeting with all the data engineers on 8 March
- Designed the relation for our feature to be included in the database schema.
- Planned activities:
- Adding a description to our relation in the database wiki
- Creating the SQL files for creation and manipulation of our tables within the database
- Assisting in API and backend development where possible, especially where the database manipulation comes into play
Sprint 2
- Updated tables within the database related to our feature
- Added CRUD operations, which handled all data access required
- Added unit tests for the operations I coded
- Helped Benjamin where I could in developing the API
Mr Matthew Gotte u20734621 - Designer, Services Engineer, UI-Engnieer
Sprint 1
- Watched resources on NestJS and learnt the CQRS pattern
- Familiarized myself with the structure/template laid out by the Architecture team
- Helped Dylan complete parts of the final mock design
- Documented what services will need to be provided moving forward for our group
Sprint 2 Took role as UI-Engineer with Mr Dylan Witheford
- Built upload story page with form validation
- Build view story modal with Dylan
- Build report modal with form validation
- Linked front end to API with Dylan
- Made front end responsive and fixed bugs in navigation
- Coded a basic fuzzy search with Dylan
Screenshots of work
Mr Dylan Whiteford u19214597 - Designer, DevOp, UI Engineer
- Kept Up to date with information going through the DevOps discussion board
- Assisted With First Few Pull Requests (may have broken the pipeline)
- Made Designs based off BA’s project spec, using the UI agreed upon by the designers (collaboration with Matthew Gotte)
- Extra:
- Setup GitHub project board, updated team sheet on the wiki
- Future plans: code the angular UI/Front-End based off the final designs (designs need approval)
Sprint 2 Took role as UI-Engineer with Mr Matthew Gotte
- setup shorts explore page
- setup navigation bar
- setup search bar
- setup the card component on the Explore page
- Coded the initial search functionality(later improved by Matthew)
Devop
- helped integrate some shared UI components
- resolved issues regarding the integration of the API
Screenshots of work Dylan Whiteford - u19214597 - 19214597.pdf