Dhaka ISP Solution

By

Md Rakibul Islam 011181002

Hamim Ahmed Komol 011181114
Emon Ahmed 011181115
Naim Uddin Ahmed Sunny 011181118
Md Toufikur Rahman Khan Sabbir 011181125

Project Supervisor
Prof. Dr. Hasan Sarwar

Course Instructor
Prof. Dr. Swakkhar Shatabda

In partial fulfillment of the criteria for the degree of

Bachelor of Science in Computer Science and Engineering, this paper has been submitted.

July 4, 2022

Department of Computer Science and Engineering

United International University
 Abstract
Now a days, people living in Dhaka who are looking forward to change their Internet connection
or if they’re new in Dhaka and looking for a new Internet connection, they would not know how
they will find the best Internet service provider based on, their location or according to their
monthly plan. It would be a hassle for them to go out and ask everyone about the Internet service
providers in their area who gives the best service and the best rate. Again, for the owner of an
internet service provider company who are looking for new customers and also a system to manage
the users and their management of ISP company, they cant find a reliable solution where they can
easily find new customers and manage all their works. That’s where our application Dhaka ISP
Solution gets in. Our Web based application will help the users to find or swap a new ISP in their
area according to their need. They can easily subscribe, pay their bills and connect with their ISP
anytime. As for the ISP they can find new users and grow their business, manage their operations,
connect with the customers through our application very easily.

i
 Acknowledgements
Many people’s contributions and support throughout the last two trimesters have made this
work feasible. We would like to express our appreciation to everyone who helped in some way.
First and foremost, we would like to express our gratitude to my academic advisors Prof.Dr.Hasan
Sarwar and Dr.Swakkhar Shatabda sir for their guideline and guidance. Without their assistance,
we would not have been able to complete our work.
Last but not least, we owe our gratitude to our family, particularly our parents, for their
unconditional love and immense emotional support .

ii
Table of Contents

Table of Contents iv

List of Figures v

List of Tables vii

1 Introduction 1
1.1 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Goal & Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Project Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 Organization of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 3
2.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Similar Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Related Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Project Design 8
3.1 Requirement Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3 Context Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4 Use Case Diagram: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.5 Data Flow Diagram Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.6 UI Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Detailed Methodology and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Task Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iii
Table of Contents Table of Contents

4 Implementation and Results 27

4.1 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Testing and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Database Implementation: . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Codes Review: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Standards and Design Constraints 41

5.1 Compliance with the Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.1 SDLC(Software Development Life Cycle) . . . . . . . . . . . . . . . . . . . 41
5.1.2 Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.3 UI (User Interface)/ UX (User Experience) . . . . . . . . . . . . . . . . . . 42
5.1.4 Version Controlling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.5 Ethics(Principals) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Design Constraints(Impact) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 Ethical Constraint(Impact) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2 Economic Constraint(Impact) . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.3 Social Constraint(Impact) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.4 Manufacturability(Impact) . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Budget & Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Complex Engineering Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.1 Knowledge Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.2 Complex Problem Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.3 Engineering Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Conclusion 51
6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

References 54

iv
List of Figures

3.1 Context Diagram for Project Design . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Use Case Diagram for Project Design . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Data Flow Diagram for Project Design . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Filter/Custom Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Search Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.7 User Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 Subscribe Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.9 User Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.10 User Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.11 ISP Registration UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.12 ISP Login UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.13 ISP Admin Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.14 ISP Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.15 ISP Add New Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.16 Bill Payment of New Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.17 Bill Payment of New Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.18 Login Super-Admin UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.19 Super-Admin Management UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.20 Super-Admin Confirmation UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.21 WBS of Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.22 Gantt Chart of project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Main Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 ISP Admin Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 ISP Packages Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Subscriber Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 User Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7 Billing Info 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8 Billing Info 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9 Review & Rating Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.10 Index.html(Homepage) Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.11 Main search.php(Search Result Page) Code . . . . . . . . . . . . . . . . . . . . . . 34
4.12 Customsearchresult.php(Custom Search Result Page) Code . . . . . . . . . . . . . 34

v
List of Figures List of Figures

4.13 ispadmin.php(Isp’s admin page) Code . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.14 ispadmin.php(Isp’s admin page) Code . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.15 ispreportsolve.php(Isp’s admin Report Solving page) Code . . . . . . . . . . . . . . 37
4.16 ispreportsolve.php(Isp’s admin Report Solving page) Code . . . . . . . . . . . . . . 38
4.17 billpayment.php Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Income By Year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

vi
List of Tables

2.1 Literature Review Geologically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Gap Analysis Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Time Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Time Allocation for project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Budget Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Mapping with knowledge profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Mapping with complex problem solving. . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5 Mapping with complex engineering activities. . . . . . . . . . . . . . . . . . . . . . 50

vii
Chapter 1

Introduction

The discussion about what we are going to do in our project, is briefly described on this chapter
1. We’ve discussed about the short description of our project in section 1.1. On section 1.2 we’ve
showed our motivation why we’re solving it. We also discussed the goal and objectives on section
1.3. All over the section we’ve contend our project’s descriptions.

1.1 Project Overview

We are going to develop a user friendly website where internet user and internet service providers(ISP)
are going to have an amazing platform to interact with each other and find the best services. Our
targeted audience are the people who living in Dhaka struggling to find a good internet service
provider and the ISP those are searching for a place to find more user as well as maintain their
user.

1.2 Motivation
According to BTRC [1] there are over 9.522 million ISP users only in Dhaka. So for the betterment
of both user and the ISP we’ve found motivation for our project which is described below:

• Nowadays most of the ISP users are not satisfied with their internet services and unfortunately
they don’t have the luxury to find and know about all the ISPs in their area that are providing
good internet services so that they can switch immediately.

• Using Our platform internet users will be able to find all the ISP in a single platform where
they can choose their desire ISP here and switch to another whenever needed.

So, based on our motivation, we’d like to create an application that can result in a positive
improvement for both sides.

1
1.3. Goal & Objectives Chapter 1. Introduction

1.3 Goal & Objectives

This section describes the goals and objectives that we intend to attain with our project.
Goal : Provide improved interaction between Internet Service Providers and Users
Objective: To develop a web-based application where all the ISP and users will interact in a
single platform so that users can find a better / desired internet service provider and ISP can find
more users and manage their operations

1.4 Methodology
We’ll create a web-based solution that will benefit both users and ISP owners. Our system allows
users to communicate with ISPs. Users will have access to a panel that will allow them to manage
their packages and payments. Users can access all of the options we offer through their control
panel. Through the ISP admin interface that we provide, the ISP can control and manage their
activities.

1.5 Project Outcome

The users and ISP owners are the primary beneficiaries of our project. Users will be able to choose
their favorite ISP, and ISPs will be able to discover new customers. It will be a win-win situation
for both ISPs and their customers.

1.6 Organization of the Report

This paper is organized into several chapters and topics. Below is a breakdown of all of them:

• Chapter 2: This chapter is about the background of our project which includes preliminaries,
literature-review, similar-applications and gap-analysis.

• Chapter 3: This chapter is about the design of our project which includes Requirement
Analysis, Functional Requirements, non-functional requirements, context diagram, data-flow
diagram level-1, UI design, detailed methodology and design, project planning and task
allocation.

• Chapter 4: This chapter is about the design of our project which includes compliance with
the standards, software development life cycle, design constraints(Impact), budget & cost
analysis and complex engineering problem.

• Chapter 5: This chapter will include the summary of the paper.

• References: All the references that are used to write the paper is included on that section.

2
Chapter 2

Background

In this chapter we’ll discuss about Literature Review on section 2.2 , similar applications that
somehow matches a little bit or more. Also the related research that are done previously and are
akin with our project. Then we’ll identify the gap with those projects on section 2.3 gap analysis.
Finally we’ll put an end to the section with summary.

2.1 Preliminaries
We’ve to know some terms to understand the entire chapter. Such type of words are:
ISP means Internet Service Providers. CP means Content Providers. SME means Small and Mid-
size Enterprise, CRM means Customer relationship management (CRM). Also churn prediction
is the process of identifying consumers who are most likely to stop using a service or end their
subscription.

2.2 Literature Review

We’ve conducted some research on the papers that are similar to our project. Furthermore, there
is little research on ISP management and the benefits of their users in the ISP context. Most of
the research that are conducted are among the business terms and their quality.
A study’s research provides a much-needed perspective on the differences between switchers and
stayers in terms of customer referral behavior [2].Again a study’s findings have brought to light
issues concerning the adoption of CRM practices and their impact on customer satisfaction[3].
Similar study investigates the problem that Taiwan’s ISP management is currently facing in de-
veloping an effective service management strategy and proposes a BI process that could assist
management in discovering in-depth knowledge of customer usage behaviors and network facility
utilization[4].
Again, the demographic characteristics have the least impact on churn prediction. However,
reaching a conclusion about the billing and usage features was not easy. These two types appear
to be equally important for predicting churn[5].
Another studies shows, Consumer decisions in a range of industries, including ISPs, are influ-
enced by online consumer reviews. This is one of the first studies to look at online user reviews
in order to provide managerial information for ISPs wanting to improve the wireless services they
deliver to their customers[6].

3
2.2. Literature Review Chapter 2. Background

Another research specifies ISPs offers the best degree of network service quality to the CP with
the most advertising income The ISP provides the other CPs with the bare minimum of network
services[7]. Another investigation shows the interplay between two ISP layers To optimize their
value, the lower tier ISP can choose the suitable traffic transmission and routing[8].
While collecting data from literature we’ve formed a table where the researches were conducted
geologically which is given in the table (2.1) below:

Economic
Paper No Paper Name Geological
Status
Customer Referral Behaviour:
01 Australia Developed
Do Switchers and Stayers Differ? [2].
On the incentives of an integrated Not Not
02
ISP to favour its own content [7]. Specified specified
Promotional Activities in Order
03 Bangladesh Developing
to Win More Customers [9].
China Developed
Achieving customer loyalty
Hong-Kong Developed
04 through service excellence in
Thailand Developed
internet industry [10].
Australia Developed
On the Interaction and Competition Not Not
05
among Internet Service Providers [8]. Specified specified
Consumer Satisfaction for Internet United
06 Service Providers: An Analysis of States of Developed
Underlying Process [4]. America
Business Intelligence approach to
07 supporting strategy-making of ISP Taiwan Developing
Service management [11].
Applying Data Mining to Customer
08 Churn Prediction in an Internet Iran Developing
Service Provider [5].
Improving Services Offered by United
09 Internet Providers by analysing States of Developed
online reviews using Text analytics [6]. America
Influence of customer relationship
10 management practices on customer Kenya Poor
satisfaction among ISP [3].

Table 2.1: Literature Review Geologically

So, we compared all of them geologically and came up with the findings that was previously
described.

2.2.1 Similar Applications

The summary of similar web applications, mobile apps similar to our work is described in this
section.
Our project main idea and Features such as area searching for ISPs, custom or filter searching
according to customer interest were compared with BTRC(Bangladesh Telecommunication Regu-
latory Commission)[1] websites. But unfortunately these sites are only providing a PDF with ISPs
names which has no good use for the customers. They don’t provide enough information that can
actually help users to find a decent ‘I&’ authentic ISP.

4
2.2. Literature Review Chapter 2. Background

A modest user panel with Review and Rating system for ISPs were not found in these 5 well
known ISPs websites shown below:

1. Triangle Services [12]:

A Bangladeshi internet service provider that offers a fully dedicated, ultra-fast, cost-effective,
and secure internet connection. We pledge to meet your requirements and provide industry-
leading customer service

2. Amber IT[13]:
Amber IT delivers a broad selection of high quality data & internet connectivity services
around the country. They offer safe internet access services with multiple service level de-
scriptions for corporate organizations and SMEs. They also provide high-availability and
consistent hosting and web development services for any business.

3. Dot Internet[14]:
Dot Internet strives to make high-quality Internet and solutions accessible to people of all
income levels.

4. Link3 [15]:
It is the country’s largest ISP in terms of active subscribers and provides broadband services.
Link3 is also a pioneer in providing integrated solutions to Bangladesh’s corporate sector,
and it is the country’s only ISP with connections to all of the country’s banks.

None of them has the review and rating system on their websites. These sites do not provide
a competent User Panel for the users where users can manage and use all their services and also
communicate with ISP whenever needed.Some of them only provides bill paying option which
remains not utilized because of poor user management.
Our ISP admin panel’s concept is compared with 4 other application providers. They are
providing similar features compared to ours. Though it may not be the same as ours but it will
be something as similar as ours. The list of those application providers are:

1. IT WAY BD[16]:
IT WAY BD offers superior solutions to help generate The Digital Delta, which itself is pow-
ered by innovation and guided by integrity. It has also astounded its visitors and associates
by establishing world-class capability to supply global solutions.

2. ISP Digital[17]:
IspDigital is a collection of technology marketing services firms that provide brands with
cutting-edge solutions.

3. AmarSheba[18]:
AmarSheba is a business platform in Dhaka, Bangladesh, where somebody may locate a
better and more dependable service provider. AmarSheba could support with a wide range
of business services, along with the creation of a strategic plan, building services and software
solutions.

4. BSD[19]:
In little customized software, BSD is really very popular. For reliable operation and analysis,
every company needs software.

5
2.2. Literature Review Chapter 2. Background

2.2.2 Related Research

We talked about the Literature Review in part 2.2. We discovered some researches related to ours
as an outcome of that. On the first research we found that The data used for this study was
collected from a leading Internet Service Provider (ISP) in certain regions and More than 16,000
account holders were emailed to participate in a customer survey [2]. On the second research
we got that result becomes equilibria when there is no integration between ISPs and CPs and
equilibria when there is integration between ISPs and CPs [7]. On the third research we’ve found
that, the data used for this study was collected from Internet Service Providers all over Bangladesh
where 80 percent were from Dhaka [9]. On the next research 2 types of loyalty analyzed first one
is attitutional and second one is behavioural [10].
Another research provides an examined data between those customers who switched their ISP
and who did not [4]. Next one provided more research on people such as their times where they
were using internet on which time. It was Conducted on 9 groups. Midnight Medium usage 6.84%,
secondly on weekend 2.56%, thirdly on overall heavy Usage 5.98%, on fourth midnight light usage
12.82%. on fifth mid-day medium Usage 4.27%, on sixth Office hour heavy usage 3.42%, on seventh
Overall lite usage 47.01%, on the eight Office Hour 8.55% and lastly office hour medium Usage
6.84% [11].

6
2.3. Gap Analysis Chapter 2. Background

2.3 Gap Analysis

From the literature review discussed on the above section we’ve found out the gaps. So, based on
those findings, there were several previous studies of a similar nature that we’ve got. The analysis
and the result is described in tabular form in table (2.2):

Paper No Paper Name Analysis

Customer Referral Behaviour:
01
Do Switchers and Stayers Differ? [2].
On the incentives of an integrated
02
ISP to favour its own content [7].
Promotional Activities in Order
03
to Win More Customers [9].
Achieving customer loyalty
04 through service excellence in
internet industry [10].
On the Interaction and Competition
05
among Internet Service Providers [8].
Deals with customer referral
behaviour according to service
quality for a particular ISP
not considering all the ISPs
Investigate the integration
between ISPs an Cp but not
among the ISPS
They talk about the how promotional
activities influence customer gain for
ISP but skip the customer satisfaction
and their opinion
Talks about achieving customer loyalty
through good services from a ISP but
didn’t show the competition between
these kind of ISPs
Shows the competitions between higher
tier ISPs and lower tier ISPs but not
considering customer interest

Table 2.2: Gap Analysis

After comparing each of the papers with each other we’ve come to an analysis & also compared
them with ours which is given on the table (2.3) below:

Summary of Gap Analysis Compared to Our’s

After Considering these paper and also 5
other papers, we can summarize that in
all those papers they tried to find how ISPs
can improve their qualities and customer’s
satisfaction in order to influence more
customers and also shows the comparison
between different types of ISPs
But none of these paper considering
that all the ISPs and customers can be
integrated into a single platform for a
better interaction and understanding
between these stakeholders

Table 2.3: Gap Analysis Comparison

7
Chapter 3

Project Design

In this chapter we would describe about the Requirement Analysis on 3.1 then we will describe
about the detailed Methodology and Design on 3.2 and then we will show our project plan and so
on.

3.1 Requirement Analysis

The process of identifying the expectations of users for a program that ought to be built or modified
is known as requirements analysis. It includes all of the tasks that are carried out in order to
determine the demands of various stakeholders. As a result, the term requirements analysis refers
to the process of analyzing, documenting, validating, and managing requirements of the software.
Elevated requirements are defined, actionable, measurable, repeatable, and traceable, and they help
in the identification of investment plans. On the Requirement Analysis section we will describe
about functional and nonfunctional Requirements.

3.1.1 Functional Requirements

The most significant functions of an application are defined by functional requirements. It is all
about an application’s functions and fundamental activities that allow a user to interact with the
system. It can be used as a standalone executable feature or as the cornerstone for the whole
software development process. From our project we have defined functional requirements into 3
perspectives. They are:

1. Functionalities from User perspective

2. Functionalities from ISP-Admin perspective

3. Functionalities from Moderator perspective

We will divide each of them to their functionalities and then describe all of them.

8
3.1. Requirement Analysis Chapter 3. Project Design

Functionalities from User perspective is also divided into 3 key features.

• ISP Searching: Users can search ISP in their local area as well as for any other loca-
tions.They also can search ISP using filter searching according to their required interest.

• Package Subscription: Users can roam through each and every ISP’s panel in their location
and check out the internet packages and available offers to subscribe their desire one’s.They
also can find the packages using filter searching where they can choose their conditions
according to their plan.

• Own User Panel : A user can easily manage his or her profile or other personal informa-
tion related to application through their own user panel. They can easily unsubscribe, pay
monthly payment, can give review, rating and complains to their subscribed ISP.

Functionalities from ISP-Admin perspective is also divided into 3 key features.

• Manage Packages: An ISP admin can manage their packages which are visible to cus-
tomers. They can add or update or delete their package. They can also provide offers for
customers to attract more of them.

• Manage Customers: ISP admin can easily control their customer and their related ser-
vices.They can add and remove customers to their system if required. They can also review
the users complains that the users are providing and take necessary steps to solve their
problems in order to betterment their services.

• Billing Management : ISP admin can do the billing management easily. They can easily
generate their monthly balance sheet, bill collection and many more through their panel.

Functionalities from Moderator Perspective is also divided into 2 key features.

• Inspect and control: A moderator can inspect the site issues and can control the ISP
admins and the users when necessary. Moderator will solve the user or ISP admin’s problem
if arises.

• Verify user and ISP: Moderator will verify an ISP and users if they are new and willing
to join in the system. He will also keep an eye of any unusual activity done from any user or
ISP admin.

3.1.2 Non-Functional Requirements

Non-functional requirements are system quality characteristics that shape the user experience and
indicate some general, abstract product expectations. Non-functional criteria could be derived
from a bundle of functional requirements and implemented as a variety of proposed application.
We have divided our non function requirement into 2 criteria. They are:

1. Non-Functionalities from ISP-Admin perspective

2. Non-Functionalities from User perspective

Non-Functionalities from ISP-Admin perspective is also divided into 3 key features.

• Maintainability: Our application is easy to maintain and bugs free for the both users ad
ISP admins.

9
3.1. Requirement Analysis Chapter 3. Project Design

• Scalability: We will have enough memory, multiple servers, disc space for the better load
management and reliable domain and hosting providers to ensure the continuous and stable
service.

• Reusability: We have made sure that the ISP Admin can quickly perform tasks in the
panel.

Non-Functionalities from User perspective is also divided into 3 key features.

• Usability: We have to assure easy system and interface so that users can performs their
tasks quickly in the easiest way and complete their actions accurately.
It enables a variety of user operations and only displays an error when anything is truly
wrong. This is accomplished by determining the amount, kind, and severity of common user
errors, as well as the ease with which users may recover from those errors.
New users will have no trouble achieving their objectives, and will have much more success
on subsequent visits.

• Security: We have to provide data privacy policy and customer data protection so that no
one can misuse the users and ISPs personal and confidential information’s.

• Accessibility: Accessibility refers to whether or not a product or service may be used by

anyone, regardless of how they come across it. Although accessibility regulations exist to help
persons with disabilities.So, designers should make every effort to accommodate all possible
users in a variety of settings. This offers clear advantages, most notably better designs for
everyone. We have to make sure that the system runs thoroughly while used by a user or
customer.

10
3.1. Requirement Analysis Chapter 3. Project Design

3.1.3 Context Diagram

Context diagrams depict how a system interacts with other actors (external factors) with whom
it is supposed to engage. System context diagrams can aid in comprehending the environment in
which the system will operate. They can be included in a requirements document and are used
early in a project to achieve consensus on the scope. The entire system is depicted as a single
process in a context diagram.
The context diagram which is figured at (3.1) has the Context depict of the system in question as
a single high-level process, followed by the system’s connection with other external entities.

Figure 3.1: Context Diagram for Project Design

11
3.1. Requirement Analysis Chapter 3. Project Design

3.1.4 Use Case Diagram:

The use case diagram below (3.2) is condensing information about our product and the users within
it. It is displayed as a graphic representation of how various system components interacting with
one another. It is detailing the system’s events and the order in which they are being implemented.
In that diagram we have shown the visitor, registered user, ISP admin & the super admin. Their
work through the application is being illustrated below.

Figure 3.2: Use Case Diagram for Project Design

12
3.1. Requirement Analysis Chapter 3. Project Design

3.1.5 Data Flow Diagram Level 1

Data flow diagram which is added below (3.3) has the information that shows how it flows through
a system or during a process. It displays varied amount of complexity and assist non-technical
audiences in comprehending way our data moves throughout our application.

Figure 3.3: Data Flow Diagram for Project Design

13
3.1. Requirement Analysis Chapter 3. Project Design

3.1.6 UI Design
In this section we will show some of the UI that we have designed for our project. Those UIs are
designs for our important features of our project. The picture below (3.4) is for the homepage for
our project. User can search their desired ISP from the search bar by submitting their location.
Also they can go to other pages like user sign-up, user login, ISP sign-up & the ISP login page.

Figure 3.4: Homepage

Filter / Custom Search UI

The picture below (3.5) is for the custom or filter searching feature where users can select the
attributes of their interest to search ISP. From that page user can select multiple fields regarding
their choice as they need. Such as they can select bandwidth speed, the price range of package,
their area & by the rating of each ISPs. After the click of search button the user will be redirected
to the result page & could be able to see the result as they wanted.

Figure 3.5: Filter/Custom Search

14
3.1. Requirement Analysis Chapter 3. Project Design

Filter / Custom Search Result UI:

The picture below is for the custom or filter searching feature. The results are shown in that page.
From that page user can select multiple fields regarding their choice as they need. The following
page (3.6) is showing how the searching result will be shown to customer.

Figure 3.6: Search Result

Customer Registration UI:

From that particular page an user can easily register to our application. From his given username
and password he can easily log in from the user login page. The picture below (3.7) is for the
customer Registration.

Figure 3.7: User Registration

15
3.1. Requirement Analysis Chapter 3. Project Design

Customer subscription UI:

When the customer clicks on a link of an ISP the user will be automatically redirected to a ISP’s
page that he has clicked. From that page an user can easily subscribe to a package that he wants
to & the ISP will get notified that a customer has subscribed. This following ui (3.8) represents
how the users will see the packages and subscription option from ISP pages.

Figure 3.8: Subscribe Package

Customer Panel UI:

From that panel an user can easily manage their subscription, monthly billing, cancellation of a
subscription, report an issue to the ISP & many more from his panel. The picture below (3.9) is
design for the user profile and control panel.

Figure 3.9: User Panel

16
3.1. Requirement Analysis Chapter 3. Project Design

Subscription UI:

From the subscription panel an user can manage their subscription if multiple ISPs are subscribed
from his ID. Also he can unsubscribe or visit to the ISP page for more information. The following
figure (3.10) from user panel showing all the subscribed packages and According ISPs.

Figure 3.10: User Subscriptions

ISP-Registration UI:

From that particular page an ISP can easily register to our application. From his given username
and password he can easily log in from the ISP login page. The picture below (3.11) is for the ISP
Registration.

Figure 3.11: ISP Registration UI

17
3.1. Requirement Analysis Chapter 3. Project Design

ISP-Login UI:

From that particular page an ISP can easily login to their ISP panel from his given username and
password. The picture below (3.12) is for the ISP Registration.

Figure 3.12: ISP Login UI

ISP Admin-Panel UI:

From the ISP admin page an ISP admin can easily manage his homepage with his packages. He
can add new packages or update the existing package from the ISP panel of his own. The picture
below (3.13) to design of ISP home page where they will show their packages and offers.

Figure 3.13: ISP Admin Panel

18
3.1. Requirement Analysis Chapter 3. Project Design

ISP Report management panel UI:

From that particular page an ISP can easily manage their any subscriber’s issue when a subscriber
submits a report from the user panel. The ISP can solve the problem from his own end & can
leave a reply message from that panel. The following figures (3.14) is the list of their subscribers
and their report details.

Figure 3.14: ISP Subscriber

ISP Add-Package UI:

From that particular page an ISP can easily add a new package from their panel. He can add
package name, speed, price & also the offer price. The following image (3.15) is the list of their
subscribers and their report details.

Figure 3.15: ISP Add New Package

19
3.1. Requirement Analysis Chapter 3. Project Design

New Package Subscription Bill Payment UI:

The image below (3.16) shows, a user paying to the ISP where he wants to subscribe into a new
package. After confirming the payment the user will be automatically subscribed to the new
package he wants to from any ISPs.

Figure 3.16: Bill Payment of New Subscription

Monthly Bill Payment UI:

The image below (3.17) shows, a user paying to the ISP for his monthly payment. He can select
each month of paying from the admin panel & whatever months he wants. After successful payment
his panel will show his payment & his connection will not be interrupted.

Figure 3.17: Bill Payment of New Subscription

20
3.1. Requirement Analysis Chapter 3. Project Design

Super Admin-Login UI:

The super admin who controls the all ISP & their sign-up request has a admin panel which has to
be accessed by the login page. From the valid login the super admin can access the request that
the ISPs have made. The following image (3.18) is the login page for super admin.

Figure 3.18: Login Super-Admin UI

Super Admin-Manage UI:

The super admin can see the sign-up request that the ISPs has requested to join the community.
The super admin can select & approve if the ISP is valid or not. The following image (3.19) is the
login page for super admin.

Figure 3.19: Super-Admin Management UI

21
3.1. Requirement Analysis Chapter 3. Project Design

Super Admin-Confirmation UI:

The super admin can see the sign-up request that the ISPs has requested to join the community.
After clicking of view details the super admin will go the acceptation page & can easily accept or
reject any ISP if he wants. The following image (3.20) is the login page for super admin.

Figure 3.20: Super-Admin Confirmation UI

22
3.2. Detailed Methodology and Design Chapter 3. Project Design

3.2 Detailed Methodology and Design

On this section we have described about the Software Requirements Specifications and the Detailed
Methodology and Design for our project. Our Software Requirements Specifications are organized
into three categories. They are:

• Software

• Programming Languages

• Hardware

We have gone over each one separately here. For the Software part we will use the following
software that are run on a Windows based personal computers. They are:

• Visual Studio-Code 1.63

• PyCharm 2021.3.1

• XAMPP 7.4.27

• Adobe XD

For the Programming Languages part we will use the following languages as wee need to
implement our project. They are:

• HTML5, CSS3

• JavaScript ES6

• Python 3.10.1

• MySQL (8.0.27)

• PHP (Optional)

For the Hardware part we will use our personal computer and we will also use a hosting server to
get our application live on the server. There is a requirement that we will need from the Server
we choose. For the server the requirement is given below:

• Python Server

• Ram-4gb or more when needed

• SSD Storage

• 99.99% Uptime

• DDOS Protection

• Dual Firewall

• SSL Certificate

• Unlimited- Database

• Asia based server

23
3.3. Project Plan Chapter 3. Project Design

• Web Based Emails

Our server specifications may vary overtime as our application upgrades. As well as we will need
enough resource to implement our project. As for we will need personal computer to implement
our project.

3.3 Project Plan

This section will discuss our project plan and how we will complete our project in the upcoming
months. There is a Work Breakdown Structure(WBS) (3.21) of our project is given below. This
WBS shows the tasks and sub-tasks to be done for our project.

Figure 3.21: WBS of Project Plan

24
3.4. Task Allocation Chapter 3. Project Design

3.4 Task Allocation

In this section, we will discuss time estimation as well as time allocations for our project. On this
table (3.1) below we have estimated a time for our project which is given in work hours in a week
or months.

Estimation Total Time

Time Given
Task List of Hours Hours
in a Week
In a Week In a Month
4 Weeks =
Requirements 3 Days 9 Work Hour
36 Work Hour
4 Weeks =
Analysis 3 Days 9 Work Hour
36 Work Hour
2 Week =
Design 3 Days 15 Wrok Hour
30 Work Hour
12 Weeks =
Implementation 3 Days 15 Work Hour
180 Work Hours

Table 3.1: Time Estimation

We have also compared our time estimations with some similar applications by Delphi Esti-
mation method and finalized the time that we are going to need for our project in the table (3.2)
below:

Estimation Round 1 Round 2 Final Estimation

Task List
from Previous (Similar Project) (Similar Project) (Least Time)
36 Work Hours
Requirements 36 Work Hour 45 Work Hour 40 Work Hour or
4 Weeks
36 Work Hours
Analysis 36 Work Hour 42 Work Hour 45 Work Hour or
4 Weeks
30 Work Hours
Design 30 Work Hour 40 Work Hour 35 Work Hour or
2 Weeks
180 Work Hours
Implementation 180 Work Hour 200 Work Hour 190 Work Hour or
12 Weeks

Table 3.2: Time Allocation for project

On the table (3.2) above we are estimating our time that we are going to need for the project.
From that time that we estimated we have formed a Gantt Chart (3.22) that we will follow to the
end which is given below:

25
3.5. Summary Chapter 3. Project Design

Figure 3.22: Gantt Chart of project

The Gantt chart above (3.22) describes the time that we have have worked on the project.

3.5 Summary
On the basis of our project we have done the requirement analysis which consisted the functional
and non-functional requirements. Then there is context diagram which shows the context of design.
Then also the data-flow diagram to show how the features works throughout the system. Then
the mock UI designing which slightly gives an idea how the system will look. Also the detailed
methodology and design describes the methods of our application. On the project planning section
we described the planning to imply our project on time and finally we calculated the allocation of
tasks.

26
Chapter 4

Implementation and Results

This chapter will cover implementation and the results that we will obtain following testing. In
addition, we’ll debate the evaluation and its findings before moving on to other topics.

4.1 Environment Setup

We employed HTML5 and CSS3, Bootstrap, and JavaScript for front-end development throughout
the environmental setup process and project completion. We used databases that are connected
through MySql for the back end. For the localhost, we used XAMPP.

4.2 Testing and Evaluation

While implementing, we tested our software a number of times and discovered numerous issues.
However, we have transformed our product from a demo application to a version-1 application
with regards to all difficulties. Therefore, each of the features for that version has been evaluated.

4.2.1 Database Implementation:

We have created database with the help of XAMPP & used Mysql as language. The following
image (4.1) shows the all of table that are used to run our software. We will talk about each of
them on that section.

Figure 4.1: Main Database

27
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Database of ISP Admin:

This data table contains the information for each of the ISPs that are connected to our application.
They have been provided an ISP id & password from the super admin panel. Also it has their
rating which will be analyzed from the user rating section and connected to here. The following
image (4.2) shows the data of ISP admins of all areas & also their area coverage rating and related
information.

Figure 4.2: ISP Admin Info

Database of ISP Package Info:

This data table on the following image (4.3) shows the information of all the ISPs and their offered
packages. This also shows their package cost, their offers & related information.

Figure 4.3: ISP Packages Info

28
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Database of Subscriber Info:

This data table on the following image (4.4) shows the information of all the Subscribers and their
ISP id on which they are connected or subscribed to. It also shows their package info, package
speed, their complain & also reply form their subscribed ISP.

Figure 4.4: Subscriber Info

Database of User:

This data table on the following image (4.5) shows the information of all the Users and their
personal information. Such as their email, address, mobile number, user id & many more related
information.

Figure 4.5: User Data

29
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Database of User Info:

This data table on the following image (4.6) shows the information of all the Users and their
personal information. Such as their user id, subscribed ISP id, package name, subscription fee &
many more related information.

Figure 4.6: User Info

Database of Billing Info:

This data table on the following image (4.7) shows the information of all the Users & their billing
information month wise. Again on the next database (4.8) we can see that the transaction id is
also there. The ISP admin can verify with the transaction id, if the user has really paid or not for
better security.

Figure 4.7: Billing Info 1

30
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Figure 4.8: Billing Info 2

Database of Review & Rating:

This data table on the following image (4.9) shows the information of all the ISPs and their ratings.
The summed up rating is coming from the user info data table (4.5) where the users can talk about
their service & provide ratings upon their experience. From all that info the summed up rating
will come & user will be able to see on the ISP page while searching. They can watch the ratings
and select their desired ISP from there.

Figure 4.9: Review & Rating Info

31
4.2. Testing and Evaluation Chapter 4. Implementation and Results

4.2.2 Codes Review:

In that particular section we are going to show the codes that we have implemented for our project.
As our code base is much complicated we can not show all of them here. Instead we are going to
show some main features & their connected codes.

Code Review of (index.html) Page:

On that particular page a user or isp could able to search their desired ISP & from that page user
could go to registration or to the login page & same goes for the ISPs. The codes shown below
(4.10) confirms those features.

32
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Figure 4.10: Index.html(Homepage) Code

Code Review of (mainsearch.php) Page:

On that particular page a user can find the results that he is expecting from the homepage. From
that result user can visit his desired ISP. The codes shown below (4.11) confirms those features.

33
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Figure 4.11: Main search.php(Search Result Page) Code

Code Review of (Customsearchresult.php) Page:

On that particular page a user can find the results that he is expecting from the Custom Search
page. He could search as he wants his package, isp, location etc. From that result user can visit
his desired ISP. The codes shown below (4.12) confirms those features.

Figure 4.12: Customsearchresult.php(Custom Search Result Page) Code

34
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Code Review of (ispadmin.php) Page:

On that particular page an ISP admin can modify their information such as their packages. Also
they can add a new package as they need or prefer. The page also contains the redirection to
another pages such as to the report management page. The codes shown below (4.13) confirms
those features.

Figure 4.13: ispadmin.php(Isp’s admin page) Code

35
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Figure 4.14: ispadmin.php(Isp’s admin page) Code

36
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Code Review of (ispreportsolve.php) Page:

On that particular page an ISP admin can can solve any customer’s report that the subscribers
have given about their service. Also they can solve the issue from that panel and give report to
the user as the problem has been solved. The codes shown below (4.15) confirms those features.

Figure 4.15: ispreportsolve.php(Isp’s admin Report Solving page) Code

37
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Figure 4.16: ispreportsolve.php(Isp’s admin Report Solving page) Code

38
4.2. Testing and Evaluation Chapter 4. Implementation and Results

Code Review of (billing.php) Page:

The following images (4.17) shows that the users can select a new subscription from the ISP page
& from there they can pay their payment. Also there is a monthly payment method from the user
panel.

Figure 4.17: billpayment.php Code

39
4.3. Results and Discussion Chapter 4. Implementation and Results

4.3 Results and Discussion

This section will cover what we accomplished for this project and how each page of the project will
function. Here, the underlying concept will also be fully covered. Then, we’ll talk about potential
outcomes for both the front-end and the back-end.
On the first homepage (3.4) we can see that, User can search their desired ISP from the search
bar by submitting their location. Also they can go to other pages like user sign-up, user login, ISP
sign-up & the ISP login page. From the homepage they can easily visit to the Custom or Filter
searching page (3.5). where they can choose the search criteria that are important to them. The
user can choose as many fields related to their decision from that page as they require. They can
choose their area, their price range, their bandwidth speed, and the overall rating of each ISP. The
user will be taken to the results page after clicking the search button and may be able to view the
results as desired there. After submitting his selection, he can see the results on that page (3.6).
The user can choose as many fields related to their decision from that page as they require.
A user can easily subscribe to our application through the user registration page (3.7). From
his given username and password he can easily log in from the user login page. After his logging
in he can visit any of ISP page & From that page an user can easily subscribe to a package that
he wants to & the ISP will get notified that a customer has subscribed. The ISP package page
(3.8) represents how the users will see the packages and subscription option from there. If a user
is subscribed to any particular ISP or not he can manage it from the customer panel (3.9). Also,
If a person has multiple ISP subscriptions linked to his ID, he can control them all from the
subscription panel. He can also unsubscribe or go to the ISP page for further details (3.10).
An ISP can easily register to our application (3.11). From his given username and password he
can easily log in from the ISP login page (3.12). After his successful login he would be redirected to
his admin panel homepage (3.13). An ISP administrator can quickly manage his site and packages
from the ISP admin page. From his personal ISP panel, he can add new packages or update the
ones that are already there. From there he can visit the ISP Report management panel. When a
subscriber submits a report through the user panel, the ISP can simply handle any subscriber’s
issue from that specific page. The ISP can resolve the issue on his own and post a response from
that panel (3.14). From the ISP Admin page, an ISP may quickly add a new package. An ISP
can easily add a new bundle from their panel from that specific page (3.15). He has the option to
enter the package’s name, speed, price, and offer price.
The login page is required to access go get into the super admin’s panel, which oversees all
ISPs and their sign-up requests. The super admin can access the request made by the ISPs via the
legitimate login (3.18). The super admin is responsible for maintaining the system sustainability.

4.4 Summary
Throughout this chapter, we’ve talked about testing, implementation, and the outcomes that
followed. During the environmental setup process and project completion, we used HTML5 and
CSS3, Bootstrap, and JavaScript for front-end development. For the back end, we used databases
connected via MySql. We utilized XAMPP for the localhost. The project evaluation for our
project has been summed up. We also talked about the testing we did on our features. Finally,
upon examination, the deliverable has been identified.

40
Chapter 5

Standards and Design Constraints

In this section we are going to describe about the methods and design along with the Standards
and Constraints in section 4.2 also about the budget and cost analysis on section 4.3

5.1 Compliance with the Standards

Software standards are a set of vocabulary, concepts, different data, documentation styles, and
methodologies that software developers agree on so that their programs can understand the files
and data generated by other programs. A protocol must be adopted and incorporated by a team
of developers who assist towards the definition and maintenance of the standard before it can be
deemed a standard.
So for our application (DHAKA ISP SOLUTION), we have decided some topics that will follow
the standards. The standards are:

• SDLC(Software Development Life Cycle)

• Coding

• UI (User Interface)/ UX (User Experience)

• Version Controlling

• Ethics(Principals)

We will describe them all one by one and talk about why we decided them to be our application’s
standards.

5.1.1 SDLC(Software Development Life Cycle)

We have decided to choose agile methodology to be used for our SDLC. Because it has some facilities
that will help in our implementation cycle. Because of the facility of simultaneous development
and delivery it would be easy for us to work more in numbers. It’s also straightforward to evaluate
performance in segments. It encourages collaboration and cross-training among the team members.
It’s also better for vast projects and as our project will also be large we can undoubtedly use Agile
for our project. And last but not least it follows the sprint method and we can redo our fault
works easily to make them right and has the lower risk factors. So for those facilities we have used
Agile for our SDLC on our project.

41
5.1. Compliance with the Standards Chapter 5. Standards and Design Constraints

5.1.2 Coding
As our application is python based, we have used the standards of PEP-8:Style Guide for Python
Code. As we have used JavaScript we also followed its coding guidelines as needed.

5.1.3 UI (User Interface)/ UX (User Experience)

For the better UI design we have followed the google’s material design guideline. Also for better
User Experience we have followed Adobe’s UX design Guideline.

5.1.4 Version Controlling

For the version controlling and the collaboration among our members we have used the Git system.
Because Git provides more functionalities than we expect. It easier to track history, create backups,
easy to collaborate, easier in branching and also for the distributed development Git is more efficient
than others.

5.1.5 Ethics(Principals)
We’ve broken down our ethical principles into eight categories. They’re all detailed below, indi-
vidually.

1. Product: Software engineers must guarantee that the software on which they work is helpful
and of adequate standard to the community, the employer, the client, and the user; that it
is produced on time and at a lower cost; and that it is error-free, to the greatest extent.
Software engineers, in particular, must, when needed.

• Verify that the software requirements on which they operate are adequately documented,
satisfy the user’s needs, and have the client’s consent.
• Ensure that each project on which they work or propose has acceptable and attainable
goals and expectations.
• Ensure that the software and related papers on which they work are thoroughly tested,
debugged, and reviewed.

2. Public: Software engineers must operate in ways which are consistent with the safety of the
community, security, and welfare in their professional roles for the public.

• Any current or perceived threat to the user, a third party, or perhaps the environ-
ment that they presume is associated with the software or relevant materials for which
they are accountable, or merely know about, should be disclosed to relevant persons or
authorities.
• Not putting one’s own personality, an employer’s benefit, a client’s involvement, or a
user’s interest before the interest of the public.
• Make an effort to create software that is inclusive. Language, unique abilities, access
controls, psychological connect, economic benefit, and resource allocation should all be
taken into account.
• When the opportunity arises, contribute expert skills to the test causes and participate
in public awareness in the discipline.

42
5.1. Compliance with the Standards Chapter 5. Standards and Design Constraints

3. Judgement: Software engineers must defend both the impartiality of their clinical judge-
ment and their credibility for such expertise, to the greatest extent and consistent with
Principle and follow such judgments.

• Maintain a strong impartiality when evaluating any software or associated papers they
are given.
• Sign only documents that are prepared beneath their oversight and then within their
areas of expertise.
• Receive payment only from one client for whichever given project or service, unless the
circumstances have been fully revealed to the parties involved and they have provided
their assent.

4. Client & Employer: In professional matters, software engineers must always operate as
loyal representatives and fiduciaries of their client or employer, consistent with public health,
safety, and welfare and follow given rules.

• Use a client’s or employer’s property only within ways that have been officially permit-
ted, and only with the client’s or employer’s knowledge and approval.
• Detect, record, and disclose any faults or issues of social significance in the software or
associated documents about which they operate or part to their employer or client.

5. Management: A software engineer in a common managerial position must act properly and
enable and support those they supervise to fulfill their individual and collective responsibili-
ties, including those outlined in this code. Those software developers in leadership positions,
in particular must follow the rules below.

• Assign tasks only after considering the acceptable benefits of training and experience,
as well as a willingness to expand on those contributions.
• Allowing a superior to take a better position for which he or she is competent is not
unjustifiable.
• Asking an employee to do something that violates this guideline is not a good idea.

6. Profession: In all professional affairs, software engineers must promote the integrity of
their profession in a manner that is compatible with healthcare system, security, and welfare.
Software engineers, in particular must follow the rules of profession described below.

• Only work with recognized companies and organizations.

• Assist in the creation of a work atmosphere that encourages ethical behavior.
• Accept only remuneration that is commensurate with your professional credentials or
expertise.

7. Colleagues: Software developers must treat all of their coworkers fairly and take proactive
measures to promote collegiality. Software engineers, in particular must follow the rules
below for colleagues.

• Others’ work should be fully acknowledged.

• Examine the work of others in a neutral, frank, and well-documented manner.

43
5.2. Design Constraints(Impact) Chapter 5. Standards and Design Constraints

8. Self: Throughout their careers, software engineers should try to improve their abilities to
advance their career as it should have been practiced. Software engineers, in particular, must
always strive to the following rules.

• Enhance their knowledge of the technology and papers they deal with, as well as the
context in which they’re utilized.
• Improve their understanding of the code, how to read it, and how to apply it to their
task.
• Avoid from pressuring or persuading everyone else to take necessary steps that would
violate the code.

Those were the ethics that we have chosen to deal our project with as to be followed carefully in
a well behavioural manner.

5.2 Design Constraints(Impact)

We have broken down our Design Constraints into four categories. They’re all detailed below,
individually. They are:

• Ethical Constraint(Impact)

• Economic Constraint(Impact)

• Social Constraint(Impact)

• Manufacturability(Impact)

We will describe them all one by one and talk about why we decided them to be our application’s
design constraints.

5.2.1 Ethical Constraint(Impact)

As per as the ethical constraints covers we have found the Data privacy part on it as for only that
relates to our project.

• Data Privacy: If system control falls into the wrong hands, confidential material could be
used for unethical purposes.

5.2.2 Economic Constraint(Impact)

In terms of ethical limitations, we found the return value, long term impact, cheaper or easier to
achieve section to be the most relevant to our study.

• Return Value: If the project fails to convince ISPs and users to participate, this may be a
waste of money and resources.

• Long Term Impact: We can expand this project to the entire country later if it proves to
be a success, as the ISP is expected to grow over time.

• Cheaper or easier to Achieve: Customers are allowed to access services rapidly and
effortlessly, while ISPs will indeed be able to obtain valuable customers in the most efficient
manner possible.

44
5.2. Design Constraints(Impact) Chapter 5. Standards and Design Constraints

5.2.3 Social Constraint(Impact)

We found the Competition part to be the most relevant to our study in terms of social constraint.

• Competition: The presence of all ISPs and users on a single platform might very well
increase competition among ISP companies, resulting in higher service quality.

5.2.4 Manufacturability(Impact)
In terms of manufacturability, we have found the profit part to be the most relevant to our research.

• Profit: Making a profit in the early stages may be difficult without investment.

These were our project’s Design Constraints (Impact). It could change depending on whether our
application improves or degrades over time. The less negative impact that could occur, the more
reliant our application will be in the future.

45
5.3. Budget & Cost Analysis Chapter 5. Standards and Design Constraints

5.3 Budget & Cost Analysis

In this section, we will provide our project’s overall budget and estimation. After that, we will
look at the cost analysis and income. As we can see in table (5.1) there is an investment that
is called Discount for Users On subscription Fee. The calculation for that particular section was
different. Suppose 500 new subscribers are subscribed to different ISPs. So in 12 months there will
be 6000 new subscribers. If we estimate that each ISP charges an amount of 1500 taka for new
subscription and we will give an extra 25% discount on a new subscription to the users then in a
month we give (500 * 500) = 25000 taka discount on a month and if multiplied by 12 months it
generates about 300,000 taka discount on a year. Rest of the investments are also calculated for a
year only.

Invested on Time Period Budget(Taka)

Domain 1 Year 1000
Hosting on
1 Year 12000
Server
Fieldwork 1 Year 100,000
Discount for Users
1 Year 300,000
On subscription Fee
Advertisement and
1 Year 100,000
Promotion

Table 5.1: Budget Analysis

As we have estimated a budget, we have also estimated an income source from it. As we can
see on the cost analysis table (5.2) we have the income source only from the ISPs. As we have
mentioned earlier that 6000 subscribers are using our application in a year and they are subscribed
to different ISPs. So if they are paying per month to the ISP, we will charge a 5% of their monthly
payment from the ISP. So if the average payment from user is 800 taka in a month, we will charge
an extra 5% charge on that 800 taka from the ISP. That becomes 40 taka from a user. As converted
to 1 year of payment it becomes 240,000 taka income in a year for us.

Income Source Time Period Income Rate(Taka)

ISP 1 Year 240,000

Table 5.2: Cost Analysis

The budget and cost analysis that we have considered above, we can see that in the first year
there will be not as such as income rather than we have invested. But we have an estimate if we
lower our budget every year our income rate will automatically increase.

46
5.3. Budget & Cost Analysis Chapter 5. Standards and Design Constraints

Figure 5.1: Income By Year

If we see the chart (5.1) above we can see that, on the first year our budget was 350,000 taka,
year by year our budget is decreasing. As our budget is decreasing our income is also increasing.
Not that our users will not increase. As our users increase our income will be more year by year.

47
5.4. Complex Engineering Problem Chapter 5. Standards and Design Constraints

5.4 Complex Engineering Problem

5.4.1 Knowledge Profile
There are total 8 attributes in knowledge profile for complex engineering problem.We find out and
map those attributes according to our project and give the justification for them into table (5.3).

Table 5.3: Mapping with knowledge profile.

K1 K2 K3 K4 K5 K6 K7 K8
Natural Mathe- Engi- Specialist Engi- Engi- Comp- Research
Science matics neering Knowl- neering neering rehension Litera-
Funda- edge Design Practice ture
mentals
√ √ √ √ √

SDLC- Python- Project Ensure Reviewed

(Agile), (Django), Planning, device almost
Data Database- Maintain compat- 10-11
Flow knowledge- Progra- ibility, different
Diagram- (MYsql) mming & Analysis litera-
(DFD), ,HTML5, design- the Con- ture’s
UI/UX CSS3 etc. (UI/UX) strain related
design, standards to our
Version project.
con-
trol(git),
SRS

5.4.2 Complex Problem Solving

Complex Engineering Problem must have characteristics P1 and some or all from the P2 to P7.
We try to map them according to our project understanding in the table (5.4) and also justify
those points later.

Table 5.4: Mapping with complex problem solving.

P1 P2 P3 P4 P5 P6 P7
Dept of Range of Depth of Familiarity Extent of Extent of Inter-
Knowledge Conflicting Analysis of Issues Applicable Stakeholder dependence
Require- Codes Involve-
ments ment
√ √ √ √ √ √

• Depth Of Knowledge: we need to have good knowledge about programming languages

related to web-development like HTML5, CSS3 and JavaScript for front-end design and
python(Django) for back-end. We need to be aware about all updated web design technologies

48
5.4. Complex Engineering Problem Chapter 5. Standards and Design Constraints

and total understanding of database knowledge. Domain and hosting is also an important
part to add. We would need some analytical, testing and debugging skills to make sure the
project works to the expectation. There is possibility that we would use GPS for location
tracking and so a good knowledge of API’s maybe useful at some point.

• Range Of Conflicting Requirement: There are some conflicting areas in terms of ISP’s
integration as well as from development perspective. AS we going to assemble all the ISP’s
in a single platform, so there is possibility that different ISP’s may have different demand,
opinion and conditions to join this platform. So, we have to work through all of that to
make this project possible. There is also some development conflicts like choosing the right
framework and design from the numerous options and whether choosing as a web based
application is a right decision or not.

• Depth Of Analysis: There is no websites or such platform that is working on same kind
of problem. So, there is no Obvious solutions on this issue. So we need to think and analyse
from the very basic considering all the possibilities to implement this system.

• Extend Of Applicable Codes:

Maintain user’s Location privacy.
Maintain user’s data privacy.
Verification of correct information for both users and ISPs.
Ensure the best security for the websites from any outside attacks.

• Extend of Stakeholder Involvement: The website needs to control by the moderators of

the website who will be act as an internal stakeholder. And the main or external stakeholder
will be all the internet users that uses our websites.

• Interdependence: First of all, we need to collect all the data that needed to run our website
and we need process the data and through several training we have to ensure that our website
is working according to our interest and final testing to measure our website accuracy.

49
5.5. Summary Chapter 5. Standards and Design Constraints

5.4.3 Engineering Activities

In this section, We try to map some of the characteristics from the activity domain (A1 - A5) in
table (5.5) and rationalized the accordingly.

Table 5.5: Mapping with complex engineering activities.

A1 A2 A3 A4 A5
Range of re- Level of Interac- Innovation Consequences for Familiarity
sources tion society and envi-
ronment
√ √

Investigate some Interacting with

of the local ISP’s the ISP’s to con-
to estimate and vince them to join
analysis the our platform and
equipment and discussing all the
budget. terms and condi-
tions.

5.5 Summary
Based on the foregoing discussion and our research’s complicity with all of the other standards
and constraints, as well as Complex Engineering problems and Complex Engineering activities, it
is reasonable to conclude that our research is a complex engineering problem, and the solution or
conclusion of our studies is a Complex Engineering Problem solution.

50
Chapter 6

Conclusion

In this chapter, we will discuss the summary of our project, its limits, and the work that we will
perform in the future for our project.

6.1 Summary
All of the above-mentioned chapters contain information regarding our entire project. In Chapter
1, for example, we described our project overview, motivation, aims and objectives, methodology,
the project’s outcome, and explanations of each of them. Er explored the background of our
research in Chapter 2. We shared our literature reviews, analogous applications to our study,
relevant research that is tied to our research in some way or another, gap analysis, and summaries
of all of them. The project design was described in Chapter 3. We glanced at the requirements,
as well as diagrams like the context diagram and Dataflow diagram. Then, in the same chapter,
we reviewed our project’s methodology and design, as well as the project’s plan and job allocation
for each of the works we’ll be implementing. The standards and design restrictions for our project
were then discussed in the next chapter, Chapter 4. In that chapter, we also discussed our project’s
budget and cost analysis.

6.2 Limitation
Our project has some limitations. As far we are concerned about our project the limitations are
the lack of manpower in our team. Our project needs lot of manpower in the field. Though at a
time, we are confident that, our work will be a talk of the town. To get to that point, we’ll need
a lot of manpower to offer our program to users and ISPs. After that we could easily upgrade our
system time to time. As far as we are concerned software implementation, application management
isn’t a bigger deal for us. So all we could say time by time there could be limitations arising. With
a better manpower we could attain our goal easily.

51
6.3. Future Work Chapter 6. Conclusion

6.3 Future Work

As a beginner, we will only provide our service for Dhaka. After a better knowing and connection
to the industry we will provide our application’s service all over Bangladesh. We will also add new
features that we could not provide earlier. Some of the features are Mikrotik’s ISP robot software
integration, API Integration Service for SMS(Short Message Service.) and many more that we
tried to implement but could not. We shall make every effort to provide the best service possible
to our clients and consumers. We shall make every effort to reach every corner of the country in
order to assist as many individuals as possible.

52
References

[1] Bangladesh telecommunication regulatory commission, http://www.btrc.gov.bd/, 2022, Jan

2022.

[2] Alisha Stein and Balasubramani Ramaseshan. Customer referral behavior: do switchers and
stayers differ? Journal of Service Research, 18(2):229–239, 2015.

[3] Agnes M Mwangi. Influence of customer relationship management practices on customer

satisfaction among Internet service providers in Nairobi. PhD thesis, University of Nairobi,
Kenya, 2010.

[4] Sunil Erevelles, Shuba Srinivasan, and Steven Rangel. Consumer satisfaction for internet ser-
vice providers: an analysis of underlying processes. Information Technology and Management,
4(1):69–89, 2003.

[5] Afaq Alam Khan, Sanjay Jamwal, and Mohammad Mehdi Sepehri. Applying data mining to
customer churn prediction in an internet service provider. International Journal of Computer
Applications, 9(7):8–14, 2010.

[6] Suchithra Rajendran and John Fennewald. Improving services offered by internet providers
by analyzing online reviews using text analytics. arXiv preprint arXiv:2008.06957, 2020.

[7] Duarte Brito, Pedro Pereiraz, and João Vareda. On the incentives of an integrated isp to favor
its own content. 2014.

[8] Sam CM Lee and John CS Lui. On the interaction and competition among internet service
providers. IEEE Journal on Selected Areas in Communications, 26(7):1277–1283, 2008.

[9] Md Karim, Xu Zhao, et al. Promotional activities in order to win more customers: A case-
study of an isp in bangladesh, 2011.

[10] Paramaporn Thaichon, Antonio Lobo, and Ann Mitsis. Achieving customer loyalty through
service excellence in internet industry. International Journal of Quality and Service Sciences,
2014.

[11] Sheng-Tun Li, Li-Yen Shue, and Shu-Fen Lee. Business intelligence approach to supporting
strategy-making of isp service management. Expert Systems with Applications, 35(3):739–754,
2008.

[12] Triangle it,largest data and internet service provider (isp), http://www.triangle.com.bd, 2022,
Jan 2022.

53
References References

[13] Amber it ltd, https://www.amberit.com.bd/, 2022, Jan 2022.

[14] Dot internet bd, ttps://dotinternetbd.com/, 2022, Jan 2022.

[15] Link 3, largest internet service provider(isp), https://www.link3.net, 2022, Jan 2022.

[16] It way bd-software solutions, https://itwaybd.com/, 2022, Jan 2022.

[17] Isp digital bd, software solutions,https://ispdigital.com/, 2022, Jan 2021.

[18] Amarsheba bd, software solutions, https://amarsheba.com/, 2022, Jan 2022.

[19] Bangladesh software development, software solutions, http://bsdbd.com/, 2022, Jan 2022.

54