Chapter 3

METHODOLOGY

This section of the paper outlines the systematic approach for developing and

conducting the study, including details on the participants, techniques used, and the

process for evaluating data in a logical order. The methods employed include requirement

analysis, project design, project development, data gathering, statistical treatment,

sampling techniques, and testing.

3.1 Requirements Specification

Requirement analysis involves determining the needs and conditions for

developing and assessing the success or failure of a system. It covers Operational

Feasibility, Technical Feasibility, Economic Feasibility, and Schedule Feasibility

specifications.

3.1.1 Operational Feasibility

Operational feasibility evaluates how effectively a proposed system

addresses the problem by outlining the system's overall flow and subsystems. It

assesses the system's ability to meet the requirements obtained during the

requirement analysis stage, taking advantage of opportunities identified during the

scope definition process.

1
3.1.2 Technical Feasibility

The technical feasibility of the system would be assessed by evaluating

whether the system can handle the logistics of freight forwarding, including

transportation, customs clearance, and documentation. This would involve

assessing whether the system has the necessary functionality and scalability to

manage freight forwarding operations and evaluating the reliability, security, and

compatibility of the system with existing hardware and software systems.

3.1.2.1 Hardware Requirements

Computer hardware specifications provide a detailed breakdown of

the components and operations of a computer system, including vital

factors like processor speed, model, and manufacturer. For businesses of

any size, having hardware specifications that support their management

system is crucial as it can help expand their online sales potential and

drive revenue growth.

Figure 13. Hardware Specifications

2
 Figure 13 Shows the minimum requirements needed for the system

needed by the potential users of the system.

3.1.2.2 Software Requirements

The specifications for the software describe how the proposed

program will operate about its integration with the user interface,

operating speed, hardware, software portability across different platforms,

and other relevant features.

Figure 14. Software Requirements for Deployment

The software requirements for the deployment will include using

browsers such as Internet Explorer, Google Chrome, Mozilla Firefox,

Safari, etc. The operating system could be MacOS or Windows for the

web application and Android 5.0 or higher for the mobile application. In

web hosting, it must hold at least 250 GB SSD of storage with unlimited

bandwidth.

3
 Figure 15. Software Requirements for the Design and Development

Figure 15 is a table that shows the software requirements for the

web and mobile applications. The first two rows of the table show the

applications used for designing. The web browser and the XAMPP

application allow websites to be used as testing sites for the system. Visual

4
 Studio Code will be a code editor to develop the mobile and website

application. PHP with Laravel as the framework and Dart with Flutter as

the framework will be used as programming languages. Firebase will be

the database used for the system.

3.1.3 Schedule Feasibility

The concept of "schedule feasibility" pertains to whether the researchers

can finish the project within a reasonable timeframe.

Figure 16. Gantt Chart

Figure 16 showcases the timetable of how the proponents will progress in

the project and what deliverables will be developed at a set time. The chart will

guide the proponents in creating their project and is based on the capstone project

timeframe.

5
 3.1.4 Economic Feasibility

The economic feasibility of the system would be assessed by evaluating

the costs and benefits of the system. This would involve assessing the

development and implementation costs of the system, as well as evaluating the

potential cost savings and benefits that the system could provide, such as

increased efficiency and accuracy of the freight forwarding process.

Tangible

● Lebria Transport will have a working website and mobile

application that will assist the customers in creating orders

● Customers and the company will be able to track the shipments.

● Automatic allocation creates faster allocation for the orders.

Intangible

● Increase in productivity

● Increase the popularity of the company

3.2 Project Design

The section on project design contains multiple diagrams that illustrate different

system flows.

6
3.2.1 System Architecture

7
 Figure 17. System Architecture of the Developed System (Web)

Figure 17 presents the project's system architecture and management

system's structure and functionality for the Web version. Users can access the site

using a browser-equipped device and connect to the internet. The internet serves

as the medium connecting users and servers. The user's requests, entered through

the browser, will be sent to the server, which will then process and fulfill the

demands by collecting data from the database and returning it to the user via the

web server.

8
 Figure 18. System Architecture of the Developed System (Mobile)

Figure 18 presents the project's system architecture and management

system's structure and functionality for the Mobile Version. Users can access the

system using a mobile application connected to the internet. The internet serves as

the medium connecting users and servers. The user's requests, entered through the

browser, will be sent to the server, which will then process and fulfill the demands

by collecting data from the database and returning it to the user via the web

server. The driver’s application also serves as the means to use the tracking

module utilizing GPS.

9
3.2.2 Context Flow Diagram

Figure 18. Context Diagram - Web

10
 Figure 19. Context Flow Diagram - Mobile

Figure 18 depicts the context flow diagram for the web version, revolving

around 2 users: customer, driver, and admin. The web version focuses on

monitoring and managing business operations of the company. While the mobile

version, illustrated in figure 19, is primarily designed for customers’ and drivers’

use and their interaction with the company or each other. The driver’s primary

platform is the mobile version. Thus, all actions the driver is allowed to perform

are only in the mobile version. Figure n depicts the context flow diagram for the

web version with 2 users: customer and admin. Actions and system functions are

elaborated in further levels of the data flow diagram.

3.2.3 Data Flow Diagram

11
 Figure 20. Admin Data Flow Diagram - Web

Figure 20 shows the admin data flow diagram for the web version. The

admin has the ability to perform CRUD operations based on the admin user level

they are assigned. Super-admins are allowed to create, read, update, and delete

data in the system. While the admin user level is only allowed to read and update

data. Both admin user levels can access both the dashboard and reports module

which is the area where they can monitor and get business information about their

operations.

12
 Figure 21. Admin Data Flow Diagram - Mobile

Figure 21 depicts the admin data flow diagram for the mobile version. In

the mobile version, they can still update data and validate payments but cannot

access the dashboard and reporting modules which are the main monitoring and

information module.

13
 Figure 22. Customer Data Flow Diagram - Web

Figure 22 illustrates the customer data flow diagram for the web version.

Customers can create an account or login through the account module and also get

or edit their account information. In the quotation module, customers can

shipment details without creating an order and get an accurate quotation based on

their input. Ability to create orders is inside the services modules where they can

make a shipment or view their shipment status and details. Lastly, the payment

module allows them to choose their payment method and get confirmation when

their payment has been verified.

14
 Figure 23. Customer Data Flow Diagram - Mobile

Figure 23 shows that the mobile version for the customer is the same with

the web version except for an additional access to one module which is the

tracking module. Customers can see in real-time where their parcels are through

the module.

15
 Figure 24. Driver Data Flow Diagram - Mobile

Figure 24 depicts the data flow diagram of the drivers. Drivers’ access in

the system is only through the mobile version as it is the primary platform for

them to use. They have access to 3 modules which is the accounts module for

logging in, and viewing or editing their account information. They get notified by

the services module if they are assigned a delivery and view the shipment details

there. Updating delivery status is also the responsibility of the driver such as if the

parcel is successfully delivered. The Tracking module is the driver’s way of

informing the customer on where their parcel is through their phone for GPS

location tracking which is reflected on the module.

3.2.3 Use Case Diagram

A use case diagram is a type of UML (Unified Modeling Language)

diagram used to visualize the different ways users or actors interact with a system

16
or software application. It is a high-level representation of the system that

illustrates the freight forwarding system's boundaries, actors, and use cases.

Figure 25. Use Case Diagram (Web)

In Figure n., The case diagram shows the type of users that will use

the system in the web version. The users are the admin, the staff, and the

customer. Customers can create an account, edit their account information,

avail services, get an example quotation, and see the progress of their

orders on the web. The staff can create an account, edit their account

information, confirm the customer's order, see the company's schedule,

and view past transactions via the report module. The admin can do

everything, from managing the accounts to adding/deleting items from the

modules.

17
 Figure 26. Use Case Diagram (Mobile)

The case diagram shows the type of users that will use the system in the

mobile version. The users are the admin, the driver, and the customer. Customers

can create an account, edit their account information, avail services, get an

example quotation, see the progress of their orders and track their orders if it is

out for delivery. The driver can create an account, edit their account information,

see the order details, and get tracked using the application. Like in the web

version, the admin can do everything, from managing the accounts to

adding/deleting items from the modules.

18
3.2.4 System Flowchart

Text should be written in Times New Roman, 12, justified and double

spaced.Text should be written in Times New Roman, 12, justified and double

spaced.

3.2.5 Entity Relationship Diagram

Text should be written in Times New Roman, 12, justified and double

spaced.Text should be written in Times New Roman, 12, justified and double

spaced.

3.2.6 User Interface Design

Text should be written in Times New Roman, 12, justified and double

spaced.Text should be written in Times New Roman, 12, justified and double

spaced.

3.2.7 Tracking Module

This module is a feature that enables customers to monitor the movement

of their package from the point of dispatch to the destination address. This module

typically utilizes an application programming interface (API) to provide

customers with real-time updates on the status of their shipments.

Using the API, the tracking module can automatically retrieve and display

the relevant tracking information for the customer. It eliminates the need for

19
 customers to manually enter a tracking number, making the process quicker and

more seamless.

For example, a customer can log in to their account on the shipping

company's website or app, and the tracking module will automatically display any

packages that are associated with their account.

The tracking module can retrieve routing information to estimate the

package's ETA, analyzing the expected delivery date, current location, and route.

This allows for an accurate delivery window, giving customers greater visibility

and control over their shipments.

Overall, the tracking module provides customers with increased

transparency and control over their shipments, allowing them to plan accordingly

and ensure the timely delivery of their packages.

3.2.8 Automatic Scheduler Algorithm

Text should be written in Times New Roman, 12, justified and double

spaced.Text should be written in Times New Roman, 12, justified and double

spaced.

3.3 Project Development Model

Project development is the process of converting an idea or concept into a

fully functional project. It is a structured approach used by researchers to provide

a solution to a specific problem or a set of requirements. For successful project

20
development, it is essential to identify the problem's root cause, determine the

best approach, and select the optimal solution to achieve the desired outcome.

3.3.1 Scrum Methodology

Figure . SCRUM Process

The proponents will utilize the Scrum methodology to develop the project

as it is adaptable to changes. Scrum is an Agile framework used in software

development that helps teams work together to develop, deliver, and maintain

21
complex products. It uses an iterative approach to provide incremental value in

small increments, called sprints. The team plans, designs, develops, tests, and

provides a working product increment during a sprint. The Scrum process

involves several roles, including the Product Owner, Scrum Master, and

Development Team. It uses specific events, such as the Product Backlog, Sprint

Planning, Sprint Review, and Sprint Retrospective, to facilitate communication

and collaboration among team members. The Scrum methodology emphasizes

flexibility, adaptability, and continuous improvement. The methodology applies

to the project because it allows the client to issue changes while developing the

project. Scrum is also appropriate because of the schedule and setting of the

researchers, developers, and clients.

User

The Scrum process begins with the system user, which includes Lebria

Transport's customers and those who will use the product, such as the admin,

employees, and drivers.

Product Owner

The Scrum development process starts with an individual who can think

like the consumer and the stakeholder involved. In the project’s case, the co-

owner of Lebria’s Transport is the product owner. The product owner should be

knowledgeable about the business, the marketplace, and the trend to contribute

successful changes to the project. The client should first check the Interface and

features of the project before the deployment process. The product owner would

22
also break down the concept of the product, the intended users, the problems the

system must solve, and why the solutions offered would benefit the company.

Software Development Team

The software development team is the proponents themselves. The team

comprises individuals with different expertise that combines to complete the task

at hand. The team must complete the modules, which are the proposed project

solutions, to deliver a successful system to the client. The team must also have

teamwork to support each other to do tasks easier and faster.

SCRUM Meeting

The team has a meeting that lasts at least 30 minutes a day. This updates

everyone on their status and progress, to know who’s doing which and what task

and to ask for help from others.

Product Backlog

The system's development begins with the proponents interviewing the

client to know which specifications and features are needed/asked for the project.

This allows the proponents also to create a prioritized list of tasks to serve as a

guide.

Sprint Planning

Sprint planning is a crucial event in the Scrum framework, where the team

comes together to plan and prepare for the upcoming sprint. Sprint planning

typically occurs at the beginning of each sprint and involves the entire Scrum

team, including the Product Owner, the Scrum Master, and the Development

Team. During sprint planning, the Scrum team decides which individuals will

23
work on items from the product backlog during the upcoming sprint. The product

backlog is a prioritized list of features, functions, and requirements for the product

the team is developing. The first 30-day sprint will consist of developing the

account, service, and payment module. The second 30-day sprint creates the

tracking, dashboard, and scheduler module. The last 30-day sprint will be for

making the quotation and report module.

Sprint Backlog

The Sprint Backlog is created during the sprint planning meeting, where

the Scrum team selects the items from the product backlog that they will work on

during the sprint. The Development Team then breaks down the chosen items into

smaller, more manageable tasks and estimates the effort required to complete each

task. The Sprint Backlog is a living document updated throughout the sprint as

progress is made, new information is discovered, or requirements change. The

Scrum team should regularly review the Sprint Backlog during the Daily Scrum

meeting to ensure they are on track to meet their sprint goal.

Sprint Review

Sprint Review is an important Scrum event that occurs at each sprint's end.

It is a collaborative meeting where the Scrum team presents the work they have

completed during the sprint to stakeholders, the product owner, and other

interested parties. The review aims to showcase the progress made towards

achieving the sprint and overall project goals, present completed work and added

product features and functionality, and provide an opportunity for stakeholders to

ask questions and provide feedback. Additionally, it allows the team to receive

24
 feedback, which is then incorporated into their product backlog to guide their

work in the next sprint.

Sprint Retrospective

The Retrospective is a time-boxed meeting, meaning it has a fixed

duration, typically between 1-2 hours, depending on the length of the sprint. The

Scrum team, including the Product Owner, Scrum Master, and Development

Team, all participate in the Retrospective. By regularly conducting

Retrospectives, the Scrum team can improve their processes, address challenges,

and work together more efficiently and effectively. The Retrospective is essential

for creating a culture of continuous improvement within the Scrum team.

3.4 Software Testing

The researcher is responsible for conducting software testing to assess the

performance of a software program, ensuring that the generated software meets the

established criteria, and identifying errors to produce a high-quality product. Upon

completing the development phase, the researchers will evaluate the system using alpha,

beta, and user acceptance testing.

3.4.1 Alpha Testing

Alpha testing is a crucial stage in the software development process where

the developers test the software before being released to end users. It is the first

rounds of testing done after the software's development phase, and the objective is

to identify and fix any bugs, issues, or potential improvements in the system.

25
 Typically, the development team conducts alpha testing in a simulated

environment to ensure the software is error-free and meets the intended

specifications.

3.4.2 Beta Testing

Beta testing is software testing performed by real users in a real-world

environment after completing Alpha testing. Beta testing aims to evaluate the

software's functionality, usability, and overall performance and gather user

feedback to identify bugs, glitches, and other issues needed to be addressed before

releasing the software to the public.

3.4.3 User Acceptance Testing

User acceptance testing (UAT) is the final phase of software testing in

which actual end-users test the software in a real-world environment to determine

whether it meets the specified requirements and is fit for purpose. The primary

goal of UAT is to ensure that the software meets the needs of the intended users,

is easy to use, and performs as expected in a real-world scenario. UAT is

performed after alpha and beta testing before releasing the software to the public.

3.5 Software Evaluation Model

ISO 9126 is an international standard for software quality that provides a

comprehensive model for evaluating software. This model offers a framework for

evaluating software that is widely recognized and accepted across the globe. The system

will be evaluated using the following metrics by the proponents:

Efficiency

26
 This characteristic quality measures how well the software utilizes

its resources to complete tasks. Efficiency can be evaluated in terms of

criteria such as response time, throughput (i.e., how many tasks the

software can complete in a given period), and resource utilization (i.e.,

how much computing power or memory the software requires to run).

Functionality

This quality characteristic focuses on how much the software

meets its specified functional requirements. Functionality can be evaluated

in terms of criteria such as accuracy, completeness, interoperability, and

compliance with standards.

Reliability

This quality characteristic refers to the software's ability to perform

its intended functions consistently and correctly under various conditions.

Reliability can be evaluated in terms of criteria such as fault tolerance

(i.e., the software's ability to handle errors), recoverability (i.e., the ability

to restore the system after a failure), and the ability to maintain data

integrity (i.e., the ability to ensure that data is accurate and consistent).

Usability

This quality characteristic focuses on the software's ease of use and

the user experience. Usability can be evaluated in terms of criteria such as

understandability, learnability, operability, and user error protection (i.e.,

whether the software helps prevent users from making mistakes).

Maintainability

27
 This quality characteristic describes the ease with which the

software can be modified or adapted. Maintainability can be evaluated in

terms of criteria such as analyzability (i.e., whether the software can be

easily analyzed to find and fix problems), modifiability (i.e., whether the

software can be easily modified to add new features or fix bugs), and

testability (i.e., whether the software can be easily tested to ensure that

changes do not introduce new problems).

Portability

This quality characteristic refers to the software's ability to be

transferred from one environment to another. Portability can be evaluated

in terms of criteria such as adaptability (i.e., whether the software can be

easily adapted to work in different environments), installability (i.e.,

whether the software can be easily installed on other systems), and

replaceability (i.e., whether the software can be easily replaced with

another software product).

3.6 Data Gathering

The proponents interviewed the co-owner of Lebria Transport to be able to collect

information and ask questions for the system to be developed. Communication between

the two parties has been constant for accurate data to be collected. To properly prepare

for creating the system, the proponents searched the internet, read books and research

relevant to our studies, and watched tutorials. These components will be a massive help

to the project.

28
3.7 Sampling Technique

Sampling is a statistical method that involves selecting a more minor but

representative data group from a larger population. The researchers will use purposive

sampling to assess the system's acceptance among each user mentioned in the study.

Purposive sampling is when researchers intentionally select individuals or cases relevant

to their research question or objective. It helps to save time and reduce the cost of data

collection by focusing only on the most relevant participants or cases.

3.8 Respondents of the Study

At least ten (10) IT experts, forty (40) customers, two (2) owners/admins, two (2)

drivers, and two (2) staff members will be the target respondents for the sampling. The

sampling aims to test the functionality of Lebria Transport's Management systems.

Researcher knowledge is critical for this sampling strategy, but the sample selection

process is relatively straightforward.

3.9 Statistical Treatment

The researchers will utilize the weighted mean formula to interpret the gathered

data and derive an understanding of the answers.

3.9.1 Frequency Distribution

A frequency distribution shows the number of observations in intervals,

which depend on the data and analyst goals. To create it, divide values/categories

into intervals, then count comments in each gap. The count in each interval

represents the frequency distribution.

3.9.2 Arithmetic Mean

29
 The mean is essential in this study as it provides the average rating of the

system. It is calculated by adding all the values and dividing the sum by the

parameter count.

A = arithmetic mean

n = number of values

ai = data set values

30