Skip to content

gsilva00/ESOF-Project

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

TEACHER4U Development Report

Welcome to the documentation pages of the Teacher4U app!

You can find here details about the T4U, from a high-level vision to low-level implementation decisions, a kind of Software Development Report, organized by type of activities:

Contributions are expected to be made exclusively by the initial team, but we may open them to the community, after the course, in all areas and topics: requirements, technologies, development, experimentation, testing, etc.

Please contact us!

Thank you!


Business Modelling

Product Vision

Teacher4U is an application for FEUP students that manages a tutoring system for various subjects, emphasizes collaborative learning and provides efficient study tools tailored to your needs. Why is this important? Well, students like us have trouble on their studies due to not having a handy help that can teach us what we need the most, specially if we're studying alone. Teacher4U ensures a quick and easy access to help from your peers and free, solo or group tutoring sessions. It solves the lack of individual help, giving the users an oportunity to have more focused aid to their studies and provides fast and easy answers to questions other students might have had. By creating a cycle of learning through your peers, Teacher4U is a solution for any student looking for help in their studies.

Features and Assumptions

  • Tutoring sessions between 2 students: If a user wants to ask questions, they can request them in a menu visible to all users, by filling in a short form with the subject, course, year, and a short description of what they are looking for. Future tutors will have the option of viewing all the requests and deciding which request to accept, at which point, a private chat will begin between the two students.
  • Joining people with the same doubts: If a student has the same questions as an already created request, then they can join it by clicking on the "Join Me" button. When the group request is accepted by the tutor, those users who have the same question join him in a group chat.
  • Ranking system: To guarantee the reliability and quality of the educational environment, a rating will be associated with each participant's profile. The rating will be established on a scale of 1 to 5 stars. Each new profile starts with a base rating of 0 stars, which will be affected by the ratings received at the end of each tutoring session.

  • Point system: Each new profile starts with a set number of points. When users participate in a tutoring session, either as a tutor or as a tutee, they receive points based on the rating of their profile:

    • 1 star -> 6 points
    • 2 stars -> 8 points
    • 3 stars -> 10 points
    • 4 stars -> 20 points
    • 5 stars -> 40 points
  • Request list priority using points: Using the accumulated points, each student can increase the priority of their request by highlighting it in the request menu. Note that this doesn't stop students from asking their questions.

Elevator Pitch

Tired of studying alone? Having words thrown at you without any meaning? You just wished to have someone who could tell what's the meaning behind everything. Luckily, Teacher4U is available to any student who wants to achieve their goals. Sign up to our application, and knowledge will be in the palm of your hand. Whatever questions you may have, your peers will join you in a chat to teach you. Want to learn with friends? You can join your friends in a group chat. Become a teacher: if you know any topic, you can also explain to others. Teacher4U will bring FEUP students together by creating a cycle of teaching and learning. So, what are you waiting for? Join us, and start learning today!

Requirements

Domain model

A user is able to create requests, as well as join them, either as a tutor or a tutee (as shown by the UserRequest association class). Each request has a predefined subject with its own description. Each request, once it has all its participants, starts a chat.

A user, at a given time, may have pending messages in their chats. To display that information, it is necessary to store when the user has last read that chat's messages (as evidenced by the UserChat association class).

At the end of a tutoring session, all participating users rate the other users on a scale of 0 to 5. Those ratings are connected to the receiving user, but also keep information about the author for analytical purposes.

Architecture and Design

Logical architecture

UML package diagram showing a logical view of the Teacher4U System:

LogicalView

  • Mobile UI: How each page is shown in the app;
  • Request Management Logic: Handling of the users' tutoring requests;
  • Profile Management Logic: Handling of users' personal data;
  • Chat Management Logic: Handling of the users' ongoing chat rooms;
  • Firebase: Used for authentication and storing of data (users, requests, chat logs);

Physical architecture

UML deployment diagram showing a deployment view of the Teacher4U System:

DeploymentView

There are two nodes on this physical architecture diagram:

  • The Client Machine node relates to the actual T4U application, that includes the app's logic to interact with the Firebase Server
  • The Firebase Server node is the app's server, which incorporates its backend services, providing the user interface with the appropriate data for each request made, each chat message sent and each profile field modified.

Vertical prototype

The vertical prototype shows a rudimentary test app with basic functionalities in Flutter that will be expanded upon in future iterations.

Four important pages for a first-time user:

  • There is the welcome page, where there are two buttons that lead to their respective pages. There is also a log out message that is temporarily shown when the user was authenticated and logged out.
  • Upon creating an account in the sign up page, the user is taken to the main page.
  • Additionally, if a previously authenticated user has signed out, upon clicking the log-in button in the log-in page, the user is again taken to the main page.
  • The main will have four tabs (the prototype only has 1). This first tab will show a list of tutoring requests (shown as a list of "it's a ferret" placeholders in the prototype). A successful login message is temporarily shown as the user logs in.

Welcome Page Login Page

Signup Page Home Page Prototype

Project management

You can find below information and references related with the project management in our team:

Backlog:

Product backlog and Sprint backlog in a Github Projects board;

Releases:

sprint-0, sprint-1, sprint-2, sprint-3;

Sprint Planning:

Before the start of Sprint 1:

Sprint1_Start

At the end of Sprint 1:

Sprint1_End

Before the start of Sprint 2:

Sprint2_Start

At the end of Sprint 2:

Sprint2_End

Before the start of Sprint 3:

Sprint3_Start

At the end of Sprint 3:

Sprint3_End

Sprint Retrospective:

After Sprint 1:

What we did well:
  • Delegation of tasks and synergy between the people developing the front-end and the people developing the back-end.
  • Connection to Firebase Auth and Cloud Firestore was done envisioning the implementation of the next sprints' User Stories, even the low-priority ones.
  • Implementation of all planned features.
  • Fast understanding and success in using the new languages and tools. Concretely, in Flutter and Dart, which allowed us to strive for modularity of code and efficiency.
What we will do differently:
  • Dedicate more time to implementing and automating our tests, highlighting our struggle in unit testing and mocking Firebase.
  • ⁠Strengthen our planning even more to tackle future problems quickly.
  • Further develop communication to implement next sprints' more complex features, that require more people (such as the chat system).
Puzzles:
  • How to automate acceptance tests (which library to use and how to use it; custom step definitions).
  • How to properly mock and test business logic of the app (Firebase)

After Sprint 2:

What we did well:
  • Figured out how to properly develop unit tests and test Firebase Auth.
  • Implementation of all planned features and additional ones from the Product Backlog.
  • Good time management throughout the 2 weeks
What we will do differently:
  • Improve visibility and intuitiveness of user options
  • Given the small amount of user stories still in the Product Backlog, our focus will greatly increase on testing.

After Sprint 3:

What we did well:
  • Given the major strides taken in the previous sprints, especially sprint-2, the sprint 3's backlog was small and was easily achievable. Instead, as planned, our focus turned to testing and improving existing features.
What we will do differently:
  • As there will be no more sprints, we won't be doing anything differently in regards to this app's development. However, from this process and the work developed during these weeks, we've learned the importance of teamwork, good planning and reviewing, because it made the development process run smoother and smoother with every iteration. It is a good set of practices that is useful and we'll keep in mind for other projects.
Puzzles:
  • Thankfully, the questions that arose during this sprint because of infinite scrolling were answered. As this is the last sprint, there's nothing we find puzzling about the features necessary for this app.

About

FEUP L.EIC 2023/24 - 2nd Year, 2nd Semester - Project developed in the Software Engineering curricular unit

Topics

Resources

Stars

Watchers

Forks

Packages

No packages published

Contributors 5