Implementación pantallas: https://github.com/Isarquis/M-viles-Group13

1. Business Questions (BQs)

Implemented Business Questions

ProductList View - Natalia Ricaurte

Business Question	Type	Rationale
How much time does it take for the material list to be available for users? Is it under 100ms on average?	1	Measures system performance and ensures fast query response time for a seamless user experience in the product list.
How does the app handle multiple users searching for the same material simultaneously?	1	Evaluates system scalability when users use search and filter features in the ProductList screen.
How easy was it for you to find the product you were looking for? Did it take more than 5 seconds?	2	Measures efficiency of search/filtering mechanisms inside the ProductList screen to identify UX improvements.

ProductDetail View - David Zamora

Business Question	Type	Rationale
How many steps did you go through before completing a purchase? Did you feel any were unnecessary?	2	The detail screen is one of the main steps before checkout, helping us track user drop-off or friction points.
Which listing attributes (images, descriptions, seller rating) impact purchase decisions the most?	5	The detail view contains images, descriptions, and price; this allows analysis of which attributes users value.
Which marketplace features (filters, entrepreneurship, messaging) are used the most and the least?	3	From this screen, we can track how often users interact with "Rent", "Buy Now", or "Place a Bid" options.

MainPage View - Pablo Méndez

Business Question	Type	Rationale
How much time does it take for the material list to be available for users? Is it under 100ms on average?	1	Measures system performance and ensures fast query response time for a seamless user experience in the product list.
How does the app handle multiple users searching for the same material simultaneously?	1	Evaluates system scalability when users use search and filter features in the ProductList screen.

MapView - Isabella Sarquis Buitrago

Business Question	Type	Rationale
How easy is it for you to coordinate and complete the pickup process when renting or buying an item?	2	From this view we can see if being close to a possible seller makes faster the pickup proccess.
Which marketplace features (filters, entrepreneurship, messaging) are used the most and the least?	3	This view is one of the differentiators with our competitors, evaluting if this feature is used, can give us valuable information to keep developing it or search a better differentiator.
Where do users spend the most time within the app, and how can we optimize these sections for better engagement?	5	If people spent too much time on the map, maybe there is some bug that needs to be solved, as currently its main use is to contact sellers close to you.

Login & Register - Pablo R Santiago Peñaranda Urbina

Business Question	Type	Rationale
How many steps did you go through before completing a purchase? Did you feel any were unnecessary?	2	This extends beyond just purchase flow to also measure the login/registration steps. Login/register are often friction points that can cause user drop-off before transactions.
Which payment methods are most frequently used? Are there any that users avoid?	3	Evaluates system scalability when users use search and filter features in the ProductList screen.
Where do users spend the most time within the app, and how can we optimize these sections for better engagement?	5	Measures efficiency of search/filtering mechanisms inside the ProductList screen to identify UX improvements.

PostProduct - Nicolas Riveros Velandia

Business Question	Type	Rationale
How many steps did you go through before completing a purchase? Did you feel any were unnecessary?	2	Although its originally focused on purchasing, this question also applies to the post flow. Understanding user interaction in the "Post a Product" process helps optimize UX.
Which marketplace features (filters, entrepreneurship, messaging) are used the most and the least?	3	Posting a product is one of the core features. Measuring its usage frequency helps determine whether it needs UX improvements or better visibility.
Given the data recompiled from the marketplace, which materials/type of materials are being sold the most?	4	Posting a product includes selecting a category and type. Analyzing this data reveals trends in what users post, helping inform marketing strategies and partnerships.

2. Analytics Pipeline (AP)

Data Source: This layer captures user behavior and app usage data, including events, logs, and usage metrics. It collects raw data generated by users as they interact with the application, providing valuable insights into user activities and patterns.

Ingestion Layer: Firebase Firestore acts as the ingestion point for real-time events and data. It stores app events and data as they occur, ensuring that the information is captured immediately and is available for further processing.

Integration Layer: This layer consists of serverless functions that process and forward data to BigQuery. Cloud Functions for Firebase are triggered by events in Firestore, allowing for real-time data processing. These functions transform and enrich the data as needed before sending it to the storage layer.

Storage Layer: BigQuery serves as the data warehouse for large-scale structured data. It stores the processed data from the integration layer, providing a centralized repository for analysis.

BigQuery SQL: This layer involves additional processing of the data stored in BigQuery. Using BigQuery SQL, you can perform aggregations, joins, data cleaning, and complex queries to prepare the data for analysis.

Presentation Layer: The final layer is the presentation layer, where data is visualized and reported. Power BI allows for the creation of interactive dashboards, reports, and visualizations. This layer provides stakeholders with actionable insights.

Implementation Visual BQ

• Event Logging in App (Data Source): Each time a user interacts with the application, the frontend sends a structured log to Firestore.

• Ingestion Layer (Firestore): Firestore serves as the real-time ingestion point, storing the logs in the "logs" collection.

• Processing Layer (Serverless or FastAPI Service): A FastAPI service is implemented to read logs from Firestore, group, filter, or calculate metrics based on business questions (e.g., average load time, most used feature).

• Visualization Layer (Dashboard): The service generates a web dashboard using Chart.js or any visualization library to graphically display the calculated metrics.

BQ: Which marketplace features (filters, entrepreneurship, messaging) are used the most and the least?

BQ: How much time does it take for the material list to be available for users? Is it under 100ms on average?

3. Architectural Design (AD)

Component Diagram

Flutter

1. Three-Layer Modularization: Rationale: The architecture follows a clear separation into three layers: Presentation, Business Logic, and Data. This promotes clean separation of concerns, improves code readability, and facilitates maintenance and feature expansion.

2. Monolithic Architecture:

Rationale: All three layers are contained within a single Flutter application (monolith). This provides faster development, simpler deployment, and easier debugging compared to distributed architectures. Scalability is achieved through the distribution platform (App Store, Google Play) and the external services used (e.g., Firestore, Stripe).

3. Architecture Attributes:

Scalability: The app’s scalability relies on the distribution platform (e.g., App Store, Google Play) and external services (e.g., *Firestore, Stripe). The Flutter app itself runs on the user’s device and does not scale horizontally like a backend system. Scalability primarily occurs at the backend level, where services like Firestore or Stripe handle increased load and traffic.

Flexibility: Modular structure allows easy integration of new services or replacement of existing backends without major changes to the app’s architecture.

Maintainability: Clear separation into layers ensures that each part (UI, business logic, data) can be updated and maintained independently.

Modularity: The system is organized by domains (Products, Users, Bids, Transactions), improving clarity and reducing coupling within the monolithic structure.

Security: By separating the presentation, business logic, and data layers, the architecture enhances security. Sensitive data can be isolated in the data layer, and access can be controlled.

Kotlin

UniMarketplace follows a Three-Layer MVVM Architecture to ensure scalability, maintainability, and modularity and maintain a clean separation of responsabilities. The system is designed using MVVM (Model-View-ViewModel), integrating key design patterns such as Observer, Repository, and Service-Oriented Design.

The app uses the following layers:

• Presentation Layer

It uses a Main Activity to depploy the app and fragments for each designed activity, this separates de UI from the logic. The Observer pattern is used to update the UI automatically when required.

• Business Logic Layer

It uses a ViewModel per fragment, they are responsible for updating the view when needed. There are also services, which are there to handle the logic.

• Data Layer

There is a repository per main entity, product and user. Each entity is represented in a Model. This layer is responsible for managing the persistence. The repository pattern is used to ensure the business logic does not interact directly with data sources.

By using the MVVM architectural pattern it ensures scalability, as the modular structure allows easier expansion and mantainability, because the IU, business logic and data layers can be modified independently. Addiotionally, by using the repository pattern, there is data abstraction, which separates the business logic from the data layer and makes more mantainable the app in case the data base changes. Finally, by using external data sources like firebase, security is garanteed.

Deployment Design

Mobile Clients:

• iOS Application(Flutter): Developed with flutter, this app runs iOS devices and communicates with backend and storage services.

• Android Application (Kotlin): Natively developed in Kotlin, this app runs on Android devices and also interacts with the same backend and storage services.

Backend Services:

• Cloud Firestore: acts as the real-time database, storing and synchronizing structured app data such as user information, products and transactions.

Image Storage:

• AWS S3 Bucket: Securely stores images and other multimedia files uploaded by users. The mobile app access this storages to upload and download multimedia.

Rationale

• Cloud-Native Architecture: by utilizing services like Firebase and AWS S3, the app benefits from the scalability and flexibility of the cloud, reducing the need to manage a difficult infraestructure.

• Serverless Architecture: there is no need for dedicated servers for business logic, simplifying the maintenance.

• Distributed Storage: separating storage of structured data from multimedia file storage optimizes performances and efficiency in handling types of data.

Design and Architecture Patterns

• MVVM architecture: it provides a clear separation of concerns between the user interface and business logic, making the codebase more modular and easier to maintain. By isolating the ViewModel, it allows for reusability across different views, reducing code duplication and promoting efficient code reuse. Additionally, MVVM enhances testability by enabling the ViewModel to be tested independently of the view, facilitating the creation of unit tests for both business and presentation logic.

• Repository Pattern: abstracts the data access layer, providing a clean separation between business logic and data access code. This makes the application more maintainable and testable (Firestore). It improves code readability and maintainability, easier to mock repositories for unit testing.

• Service Layer Pattern: encapsulates business logic, promoting code reuse and making the application easier to manage. It interacts with the repository layer to perform CRUD operations and other business processes. Allows consistent application of business rules across multiple controllers.

• Strategy Pattern for Payment Gateway: The strategy pattern allows the application to handle different payment methods and processors efficiently. This flexibility is crucial for integrating multiple payment options and adapting to different payment providers. Flexibility to add new payment methods without modifying the core logic.

4. Implemented Features (IF)

https://drive.google.com/file/d/1rij_Q6hYZU0AKEn9HRdewbJ1BzahEju1/view?usp=sharing

1. Product listing Natalia Ricaurte

2. Product details and bids David Zamora

3. Main Page Pablo Méndez

4. Login & Register Pablo Peñaranda (Kotlin)

5. Map Isabella Sarquis

<img width="330"/>

6. Post Product View Nicolas Riveros

Kanban Board

https://sharing.clickup.com/9013611725/b/h/4-90133350236-2/9a79c7bf2a0ca47

Ethics Video

https://youtu.be/3sqAOs3d7eE