Sprint 2 marks the transition from conceptualization to actualization in our project development process. During this sprint, our team will focus on bringing our ideas to life through user interface design and initial coding. We'll start by translating our design thinking outcomes into a visually appealing and functional UI, ensuring it aligns with user needs and project goals. Subsequently, we'll dive into the development phase, building our product backlog and implementing core features. Throughout this process, we'll apply the architectural concepts, design principles, and patterns discussed in class, laying a solid foundation for our application. This sprint represents a crucial step in transforming our vision into a tangible product, setting the stage for further refinement and feature development in subsequent sprints.

For detailed documentation and deliverables, please refer to the following item list:

• MS6: Deliverable
• MS7: Deliverable

Business Questions

Type 1:

1. What is the average response time for real-time parking spot availability updates, and does it exceed our target of 1 second?

Type 2:

2. Do we have information on the cheapest spots to park?
   Yes, then we can recommend a user park on one of those spots.

2.1. Do we have real-time information on the user’s location?
Yes, then we can recommend a user park on one of those nearby spots.

3. Do we have information on what parking lots have spots available for EV use?
   Yes, then we can recommend an EV user park on one of those spots.

4. What percentage of users activate the in-app navigation feature when approaching the campus parking areas?
   Greater than 75%, then we can recommend the routes for the in-app navigation based on the insight on traffic gathered from other users’ phones.

5. On average, what parking payment option is used the most by the users of the app?
   Parking payment option XXXX, then we can arrange the parking payment option list to give more visibility to option XXXX.

Type 3:

6. Which parking-related feature (spot reservation, real-time availability, or navigation assistance) is used most frequently by our users on a weekly basis?

7. What percentage of users have clicked on the license plate recognition beta feature for automated entry?

8. Is the usage frequency of parking spots in the Santodomingo building through our app exceeding the parking lot's capacity? Consequently, should we expand to nearby independent parking lots?

Type 4:

9. We are a business that collects real-time position data about our users. What are the geographical locations within the city where many students go through at a given time while commuting?
   Those locations are X, Y, and Z, then we can sell this information to marketing agencies that are interested in advertising products to students.

Type 5:

10. How does the implementation of our real-time spot detection system impact both the app's performance metrics (such as server response time and data accuracy) and user behavior patterns (like frequency of app usage and time spent searching for parking)?

Analytics Pipeline

Above is the defined Data Pipeline for the project. Each of the layers shown were chosen based on the specifications of the app being built, our familiarity with each technology, and how well we thought they worked with each other.

For the data source, we are opting for a structured relational database, using MySQL / Firebase, depending on the availability. Given the information the app is going to handle (parking sports, routes, user profiles, etc.), we concluded that a relational database would be the easiest to manage and work with.

For the integration layer we opted for API Rest, which will communicate with our storage layer to save data to SQL Databases. As mentioned before, this choice was made primarily due to the type of data the app is going to interact with. Additionally, given the data source identified, it made sense that the data was stored in a similar way.

In the processing layer, we decided to use self hosted scripts that will handle the data being received and output the expected results. For this sprint, we identified two main functionalities, namely, the filtering and identification of parking spot given certain parameters, and the calculation of fees after someone has finished using a parking spot, given their circumstances.

Lastly, in the presentation layer, we have decide to employ software like Power BI and Tableu, to facilitate data analysis should the need present itself. The choice of these technologies was made due to the familiarity we share with said resources and because they allow for both simple and complex data views.

Architectural Design

Architecture Definition

1. Layered Architecture

The architecture is divided into three primary layers: Presentation Layer, Data Access Layer, and Mobile Support Infrastructure. This separation of concerns ensures better modularity, maintainability, and scalability of the mobile application.

Presentation Layer

This layer is responsible for managing the user interface (UI) and user interactions. It includes:

• View: The View Base and App Views components provide the UI, ensuring the application's visual representation.
• ViewModel: The ViewModel Base and App ViewModels act as intermediaries between the View and the Model, providing lifecycle-aware data-binding and managing UI-related logic. This separation allows the UI to stay reactive to changes in data.

Data Access Layer

This layer manages data processing and is divided into:

• Model: Represents the data layer, containing the business logic and data definitions.
• Data Access: This section includes Data Access Components for accessing local data or cache and Service Agents for communicating with external services. This setup ensures that data access is abstracted and reusable, making it easier to integrate with various data sources.

Mobile Support Infrastructure

This layer consists of Local Data and Cache and external Data Sources and Services.

• Local Data and Cache stores frequently used data to reduce latency and server load, enhancing the performance and scalability of the app.
• Data Sources and Services provide remote data and services, which are accessed through the Data Access Layer.

2. Architectural Style: Data Flow

The data-flow architectural style enables the smooth flow of data between the different layers, ensuring efficient handling of data transformations and updates:

• Data flow from Services is handled by Service Agents, which fetch data from remote sources.
• Data transformation occurs in the Data Access Components, where data may be cached locally for improved performance.
• The ViewModel layer observes changes in the Model and updates the Views accordingly. This unidirectional data flow ensures data consistency and reduces the chances of unexpected side effects in the application.

3. Architectural Pattern: MVVM

The MVVM (Model-ViewModel-View) pattern is chosen to separate the concerns of data management, UI logic, and UI presentation:

• The Model is isolated from the View, ensuring that business logic remains separate from UI components.
• The ViewModel exposes data to the View and reacts to changes in the underlying data through observable mechanisms, making the UI responsive and adaptive without direct coupling with the data layer.
• The View is kept as passive as possible, mainly responsible for displaying data and reacting to user input. The View binds to the ViewModel, which manages the UI logic, providing cleaner and more testable code.

4. Tactic: Database Caching for Scalability

To enhance the app's scalability, a caching strategy is employed:

• Local Data and Cache: Storing frequently accessed data locally minimizes the need to frequently request data from remote services. This not only reduces the server load but also improves application performance, especially in offline or poor network conditions.
• The Data Access Layer effectively uses local caching to serve data to the ViewModel whenever possible, falling back to service calls only when the cached data is outdated or unavailable.

5. Scalability

• The use of caching and the layered architecture enhances the system's scalability by reducing load on backend services and minimizing latency for end-users.
• The Service Agents and Data Access Components handle the complexity of interacting with external services, making it easier to adapt to changes in the backend without affecting other layers of the application.

Class-Entity Diagram

This class-entity diagram represents the core structure of the SeneParking app, designed to streamline parking management at Universidad de los Andes. The diagram illustrates the key entities and their relationships within the system.

The User class is central, connecting to Vehicle, ParkingHistory, Reservation, Payment, and Notification classes. This structure allows for comprehensive user management, including vehicle registration, parking activities tracking, and communication. The ParkingLot and ParkingSpot classes represent the physical parking infrastructure, with attributes that enable real-time availability tracking and special parking designations, such as EV charging. Reservation and Payment classes handle the booking and financial aspects of the system, ensuring smooth transactions and accurate record-keeping.

This structure supports the app's core functionalities, including real-time parking spot detection, smart access, and in-app payments, while also allowing for future expansions such as integration with nearby parking lots. The relationships between classes represent the real-world interactions between these entities, ensuring a scalable system architecture for SeneParking.

Implemented Features

Below are the implemented functionalities in the SeneParking that address the specific Business Questions (BQ), providing key features to enhance the user experience and deliver real-time, satisfactory and intelligent parking solutions:

Features

Map with real-time location

• Function: A blue dot will show the user current location in real-time, working with the mobile device location sensors.
• BQ: Do we have real-time information on the user’s location?
• Answer: Yes, this functionality identifies the user's exact location and displays nearby parking lots on the map, improving the overall parking experience helping him locate himself in the map and nearby parking spots.

Detailed information for Santo Domingo (SD) parking lots

• Function: Provide detailed information on the status of parking spots in the SD, this includes: availability, price and additional services.
• BQ: Do we have real-time information on the user’s location?
• Answer: Yes, with this, we can use his location and elaborate based on his context, using real-time location in the SD parking lot and suggest parking spots, we may even include EV spots availability withing the SD.

Smart Feature: Automated License Plate Recognition for Seamless Parking Access and Payment

• Function: This feature integrates advanced license plate recognition technology at parking lot entrances and exits. When a car approaches the entrance, the system quickly scans and recognizes the license plate, automatically opening the barrier for registered users. Upon exit, the system again recognizes the plate, calculates the parking duration, and automatically charges the user's linked account based on the time spent.
• BQ: What percentage of users have clicked on the license plate recognition beta feature for automated entry?
• Answer: This business question helps us gauge user interest and adoption of the new license plate recognition feature. A high percentage of clicks indicates strong user interest, suggesting that the feature is addressing a real need. For example, if 75% of users have clicked on the beta feature, it shows a high level of curiosity and potential adoption, indicating that we should prioritize fully implementing and refining this feature.
• Value Addition: This smart feature enhances the user experience by providing a frictionless, contactless parking process. It eliminates the need for physical tickets or access cards, reducing the potential for lost tickets or forgotten payments. The automatic calculation and charging based on actual parking time ensure fair and transparent billing. Moreover, the system can provide valuable data on parking patterns and usage, allowing for more efficient management of parking resources and potentially informing future expansion decisions.

Authentication views

• Function: Login and registration views, enabling users to authenticate and securely use the functions withing the app.
• BQ: Which parking-related feature (spot reservation, real-time availability, or navigation assistance) is used most frequently by our users on a weekly basis?
• Answer: Authentication will allow us to track behaviors and analyze the features the registered user used. That way we can know what feature is most/least used.

A pin for SD parking lots on Google Maps

• Function: Displays a pin in Google Maps that indicates the location of the available parking spots in the SD parking lot. Given that it is a parking lot with spots for electronic vehicles it is shown in blue. Parking lots without EV spots are shown in green and full parking lots are shown in red.
• BQ: Do we have real-time information on the user’s location?
• Answer: Yes, as we have the users location, we can display with the red dots only those nearby available parking spots, helping him to successfully and effectively park.

Blue pin for EV parking lots

• Function: Displays a green pin in Google Maps that indicates the location of the available EV parking spots in the SD parking lot.
• BQ: Do we have information on what parking lots have spots available for EV use?
• Answer: Yes, this feature helps EV users identify nearby available spots. Getting rid of the time it takes to locate one.

Ethics Components

Video