Tunisian Republic ‫الجمهورية التونسية‬

Ministry of Higher Education and Scientific

Research ‫وزارة التعليم العالي والبحث العلمي‬
General Directorate of Technological Studies ‫اإلدارة العامة للدراسات التكنولوجية‬
Higher Institute of Technological Studies of Rades
Computer Technologies Department
‫المعهد العالي للدراسات التكنولوجية برادس‬
‫قســم تكنولوجيات اإلعالمية‬

End of Studies Project Report

APPLIED LICENSE IN COMPUTER TECHNOLOGIES

OPTION:
DEVELOPMENT OF INFORMATION SYSTEMS

Development of a Web Application for a Topnet

Client Portal

Company: Topnet

Elaborated by: Company Supervisor: Mr. AMRI Majdi

DERBALI Karim Pedagogical Supervisor: Mr. MIAOUI Bassem
El OUNI Mohamed Dhia Elhak

Code PFE: DSI-24-28 Academic Year: 2023/2024

Address :Rue El Quods, BP 172 - 2098 - Radès

‫ رادس‬-1902-271-‫ب‬.‫ ص‬،‫ نهج القدس‬:‫العنوان‬
Téléphone : 71 460 100Fax : 71 442 322
71 442 322 :‫ الفاكس‬71 460 100 :‫الهاتف‬
Site Web : www.isetr.rnu.tn
www.isetr.rnu.tn:‫موقع الواب‬
Abstract
This project involves developing a web application for Topnet's customer portal. The aim is to
create a user-friendly interface enabling customers to manage their accounts, pay bills, request
services, and submit support tickets online. Utilizing modern web technologies, the
application enhances customer experience, improves service efficiency, and streamlines
communication with Topnet.

The development process encompasses requirement analysis, design, implementation, and

testing, with a focus on security, scalability, and responsiveness to meet diverse user needs.

Résumé
Ce projet implique le développement d'une application web pour le portail client de Topnet.
L'objectif est de créer une interface conviviale permettant aux clients de gérer leurs comptes,
payer leurs factures, demander des services et soumettre des tickets de support en ligne. En
utilisant des technologies web modernes, l'application améliore l'expérience client, optimise
l'efficacité du service et simplifie la communication avec Topnet.

Le processus de développement comprend l'analyse des besoins, la conception,

l'implémentation et les tests, avec un accent particulier sur la sécurité, l'évolutivité et la
réactivité pour répondre aux besoins divers des utilisateurs.
Dedications

We humbly dedicate this work alongside our efforts to

Our fathers
for their support, affection and trust…

Our mothers
for their endless love, encouragement and sacrifice…

Our brothers and sisters

for their unwavering moral support.

Karim Derbali
Mohamed Dhia Elhak El Ouni
 Acknowledgements

We wish to express our gratitude through these few lines to all those
who, through their presence, support, and advice, gave us the courage to
accomplish this project.

Firstly, we would like to express our profound gratitude to our supervisor,

Mr. Bassem MIAOUI, for his guidance and immense support, which he
generously provided throughout the project period.

We are deeply thankful to Mr. Majdi AMRI, who technically supervised us

during the entire internship, never hesitating to dedicate part of his valuable
time to significantly assist us in the completion of the internship.

We also wish to extend our thanks to the faculty and administrative staff
of the Higher Institute of Technological Studies of Rades for the quality of
education provided and the support from the administrative team.

Finally, we express our sincere thanks to the jury members for kindly
agreeing to review and evaluate this work.
 Table of Contents

General Introduction ......................................................................................................... 1

CHAPTER 1 : PROJECT CONTEXT AND METHODOLOGY ................................................................ 2

1. Presentation of the company ............................................................................................................ 3
2. Analysis of the current state.............................................................................................................. 5
2.1. Description of the current state ..................................................................................... 5
2.2. Criticizing the current state ............................................................................................ 5
2.3. The proposed solution .................................................................................................... 6
3. Methodology and Modeling Language ............................................................................................6
3.1. Agile Methods ................................................................................................................................ 6
3.2. Presentation of the SCRUM Methodology .............................................................................. 7
3.3. Unified Modeling Language (UML) ............................................................................................ 8

CHAPTER 2 : STUDY AND PROJECT PLANNING ............................................................................. 9

1. Requirements Specification ............................................................................................................. 10
1.1. Identification of Actors............................................................................................................... 10
1.2. Functional Requirements........................................................................................................... 10
1.3. Non-Functional Requirements ................................................................................................. 11
2. Structure and Project Planning ....................................................................................................... 12
2.1. Product Backlog ........................................................................................................................... 12
2.2. Sprint Planning ............................................................................................................................. 13
2.3. Global Use Case Diagram ........................................................................................................... 14
3. Development environment and technical choice ....................................................................... 15
3.1. Development Environment ....................................................................................................... 15
3.1.1. Hardware Environment ................................................................................................ 15
3.1.2. Software Environment ..................................................................................... 16
3.2. Technical Choices ........................................................................................................................ 17
4. Architecture of the System .............................................................................................................. 18
4.1. MVC Architecture ........................................................................................................................ 18
4.2. Application Functionality ........................................................................................................... 19
5. Release Planning ................................................................................................................................ 20

CHAPTER 3 : SPRINT 1 ................................................................................................................ 21

1. Needs Analysis .................................................................................................................................... 22
1.1. Sprint Backlog ................................................................................................................................. 22
1.2. Use Case Diagram for the First Sprint........................................................................................ 23
1.3. Use Case Analysis ........................................................................................................................... 23
1.3.1. Analysis of the "Authenticate" Case .......................................................................... 23
 1.3.2. Analysis of the “Reset Forgotten Password” case .................................................. 24
1.3.3. Analysis of the case “Manage profile” ...................................................................... 25
1.3.4. Analysis of the case “Manage bills” .................................................................. 26
2. Design ................................................................................................................................................... 27
2.1. Class Diagram for the First Sprint ................................................................................. 27
2.2. Detailed Sequence Diagrams .................................................................................................... 28
3. Implementation and Testing ........................................................................................................... 30
3.1. Implementation .......................................................................................................................... 30
3.2. Unit Testing................................................................................................................................... 35

CHAPTER 4 : SPRINT 2 ................................................................................................................ 36

1. Needs Analysis ................................................................................................................... 37
1.1. Sprint Backlog ................................................................................................................. 37
1.2. Use Case Diagram for the Second Sprint ....................................................................... 37
1.3. Use Case Analysis ........................................................................................................... 38
1.3.1. Analysis of the “Manage contracts” Case ......................................................... 38
1.3.2. Analysis of the “Manage emails accounts” Case .................................................... 39
1.3.3. Analysis of the “Submit support tickets” Case ................................................ 40
1.3.4. Analysis of the “Submit complaints” Case…………………………………………………….41
2. Design ................................................................................................................................. 42
2.1. Class Diagram for the Second Sprint .............................................................................. 42
2.2. Detailed Sequence Diagrams ......................................................................................... 43
3. Implementation and Testing ............................................................................................. 43
3.1. Implementation .............................................................................................................. 43
3.2. Unit Testing ..................................................................................................................... 46

CHAPTER 5 : SPRINT 3 ................................................................................................................ 47

1. Needs Analysis .................................................................................................................... 48
1.1. Sprint Backlog ................................................................................................................. 48
1.2. Use Case Diagram for the Third Sprint ........................................................................... 48
1.3. Use Case Analysis ........................................................................................................... 49
1.3.1. Analysis of the "Submit a request to migrate to a different service plan" Cas 49
1.3.2. Analysis of the "Provide Suggestions for Service Improvements" Case ............ 50
1.3.3. Analysis of the "Participe in satisfaction surveys" Case ........................................ 51
2. Design ................................................................................................................................. 52
2.1. Class Diagram for the Third Sprint ............................................................................... 52
2.2. Detailed Sequence Diagrams ....................................................................................... 54
3. Implementation and Testing ............................................................................................. 55
3.1. Implementation ........................................................................................................... 55
3.2. Unit Testing .................................................................................................................. 58

Conclusion .................................................................................................................................................. 59

Bibliography and Webography ........................................................................................ 60

List of Figures
Figure 1.1 : TOPNET Logo............................................................................................................................... 3
Figure 1.2 : The Headquarters of TOPNET ...................................................................................................... 4
Figure 1.3 : The Organizational Chart of TOPNET ........................................................................................... 4
Figure 1.4 : SCRUM process ............................................................................................................................ 8
Figure 2.1 : Identification of Actors .............................................................................................................. 10
Figure 2.2 : Theoretical Sprint Estimation .................................................................................................... 14
Figure 2.3 : Global Use Case Diagram ........................................................................................................... 15
Figure 2.4 : Application Functionality ........................................................................................................... 20
Figure 3.1 : Use Case Diagram for Sprint 1 ................................................................................................... 23
Figure 3.2 : "Authenticate" Use Case Diagram ............................................................................................. 23
Figure 3.3 : “Reset forgotten password” Use case ....................................................................................... 24
Figure 3.4 : "Manage profile" Use Case Diagram ......................................................................................... 25
Figure 3.5 : «Manage bills» Use Case Diagram............................................................................................. 26
Figure 3.6 : Class diagram for the first sprint ............................................................................................... 27
Figure 3.7 : Sequence Diagram "Authenticate" ............................................................................................ 28
Figure 3.8 : Sequence Diagram "Reset forgotten password" ....................................................................... 29
Figure 3.9 : Sequence Diagram "Update profile" ......................................................................................... 29
Figure 3.10 : Sequence Diagram "Paybills" ................................................................................................... 30
Figure 3.11: Login Interface .......................................................................................................................... 31
Figure 3.12 : Password Recovery Email Sending Interface ........................................................................... 31
Figure 3.13 : Reset Password Notification Interface .................................................................................... 32
Figure 3.14 : Reset Password Interface ........................................................................................................ 32
Figure 3.15 : Update Contact Information Interface .................................................................................... 33
Figure 3.16 : Bills List Interface ..................................................................................................................... 34
Figure 3.17 : Payment Interface ................................................................................................................... 34
Figure 3.18 : Result interface of the "Authenticate" test ............................................................................. 35
Figure 4.1 : Use Case Diagram for the Second Sprint ................................................................................... 38
Figure 4.2 : "Manage contracts" Use case .................................................................................................... 38
Figure 4.3 : "Manage emails accounts" Use case ......................................................................................... 39
Figure 4.4 : "Submit support tickets" Use case............................................................................................. 40
Figure 4.5 : "Submit complaints" Use case ................................................................................................... 41
Figure 4.6 : Class diagram for the second sprint .......................................................................................... 42
Figure 4.7 : Sequence Diagram "Submit complain" ...................................................................................... 43
Figure 4.8 : Contracts List Interface .............................................................................................................. 44
Figure 4.9 : Mini Contract Purchase Interface .............................................................................................. 44
Figure 4.10 : Email Account Management interface .................................................................................... 45
Figure 4.11 : Complaint Submission Interface .............................................................................................. 45
Figure 4.12 : Complaint Submission Log Test Interface................................................................................ 46
Figure 5.1 : Use Case Diagram for the Third Sprint ...................................................................................... 49
Figure 5.2 : Use Case Diagram “Submit a request to migrate to a different service plan ' Files .................. 49
Figure 5.3 : Use Case Diagram "Provide Suggestions for Service Improvements" ....................................... 50
Figure 5.4 : Use Case Diagram "Participe in satisfaction surveys" ............................................................... 51
Figure 5.5 : Class diagram for the third sprint .............................................................................................. 53
Figure 5.6 : Sequence Diagram "Line transfer request" ............................................................................... 54
Figure 5.7 : Sequence Diagram "Send Satisfaction" ..................................................................................... 54
Figure 5.8 : Service Plan Migration Request Interface ................................................................................. 55
Figure 5.9 : Line Transfer Request Interface................................................................................................. 56
Figure 5.10 : Service Enhancement Suggestions Interface ........................................................................... 57
Figure 5.11 : Satisfaction Survey Participation Interface.............................................................................. 57
Figure 5.12 : Service Plan Migration Request Log Interface ......................................................................... 58
List of Tables
Table 2.1 : Product Backlog .......................................................................................................................... 12
Table 2.2 : Description of the Development Machine………………………………………………………………………………16
Table 2.3 : Release Planning ......................................................................................................................... 20
Table 3.1 : First Sprint Backlog…………………………………………………………………………………………………………………22
Table 3.2 : Textual Description of "Authenticate" Use Case ........................................................................ 24
Table 3.3 : Textual Description of "Reset forgotten password" Use Case .................................................... 25
Table 3.4 : Textual Description of "Manage profile" Use Case ..................................................................... 26
Table 3.5: Textual Description of “Manage bills” Use Case .......................................................................... 26
Table 4.1 : Backlog for the second sprint ..................................................................................................... 37
Table 4.2 : The textual description of the "Manage contracts" use case ..................................................... 38
Table 4.3 : The textual description of the “Manage emails accounts" use case .......................................... 39
Table 4.4 : The textual description of the “Submit support tickets" use case ............................................. 40
Table 4.5 : The textual description of the “Submit complaints" use case…….……………………………………………41
Table 5.1 : Third Sprint Backlog .................................................................................................................... 48
Table 5.2 : Textual Description of "Submit a request to migrate to a different service plan" Use Case ...... 50
Table 5.3 : Textual Description of "Provide Suggestions for Service Improvements" Use Case .................. 50
Table 5.4 : Description textuelle de cas d'utilisation "Participe in satisfaction surveys" ............................. 51
 Technical Abbreviations
A
 ADSL: Asymmetric digital subscriber line
 API: Application Programming Interface
B
 BPMN: Business Process Modeling Notation
C
 CRUD: Create Read Update Delete
 CSS: Cascading Style Sheets
F
 FSI : Fournisseurs Services Internet
H
 HTTP : Hypertext Transfer Protocol
J
 JSON : JavaScript Object Notation
M
 MVC: Model View Controller
O
 OMG: Object Management Group
P
 PHP: Hypertext Preprocessor
R
 RH: Ressources Humaines
 REST: Representational State Transfer
T
 TT: Tunisie Telecom
U
UML: Unified Modeling Language
 General Introduction
At the heart of the digital era, web applications play a crucial role, resulting from the
integration of information systems and the internet. These applications encompass a multitude
of innovative tools that enable businesses to better understand and manage the services and
entities they offer. Topnet, a major player in the field of digital solutions, has decided to
modernize its processes by abandoning manual client management methods in favor of
advanced IT solutions. This initiative aims to optimize communication channels with clients
and ensure continuous and effective monitoring of their interactions and satisfaction.

In this context, and as part of our final year project, we have been tasked with developing a
web application for a client portal at Topnet. This portal aims to provide users with simple
and fast access to information about the services offered by Topnet, while facilitating
communication and feedback.

This report is structured into five chapters, each describing a key stage in the development of
this project.

In the first chapter, we will place the project in its general context by presenting the host
organization and analyzing the existing system. We will then describe the proposed solution,
as well as the chosen methodology and modeling language.

The second chapter, titled "Project Study and Planning," will cover the needs analysis, the
development of the product backlog, the distribution of sprints, the development environment,
the technical choices, and the system architecture.

The next three chapters, "Sprint 1," "Sprint 2," and "Sprint 3," will detail the functional
specifications, design, and implementation of each sprint, presenting the developed interfaces
and the challenges encountered.

This report aims to provide a comprehensive and structured overview of the development of
the Topnet client portal, thereby demonstrating the practical application of the theoretical
knowledge acquired during our studies.

1
 Chapter 1
Project Context and Methodology

2
Introduction
The framing aims to establish the scope of the project. It is also a critical step in setting the
project's direction.

Therefore, the first chapter focuses on delineating the project framework, presenting the
hosting organization, and analyzing the current state to propose a suitable solution.
Furthermore, this chapter underscores the methodology and the chosen modeling language
adapted for this project.

1. Presentation of the company

TOPNET is a Tunisian company that commenced operations on May 2nd, 2001. It stands as a
leading and pioneering entity in Internet services and Internet Service Providers (ISPs) within
Tunisia, serving both residential and professional segments.

Figure 1.1 : TOPNET Logo

The company has experienced sustained growth, holding a market share of 48% with 260,000
ADSL subscribers, a network of over 500 resellers, and 12 commercial branches nationwide.
It became a subsidiary of the Tunisie Télécom (TT) group in June 2010. This acquisition is
considered by Tunisie Télécom as a strategic move to strengthen its leadership through an
entity that, in just a few years, has risen to become a market leader in the Internet Service
Providers (ISPs) market.

3
 Figure 1.2 : The Headquarters of TOPNET

TOPNET, which employs 500 staff members, formalized its acquisition by the historic
Tunisian operator, Tunisie Telecom, in June 2010. This acquisition aligns with the strategy of
both companies aimed at bolstering TOPNET's leadership and growth in a highly dynamic yet
fiercely competitive internet market.

The company's organizational chart is as follows:

Figure 1.3 : The Organizational Chart of TOPNET

4
Our internship took place within the Customer Experience and Digital Transformation
department for a duration of 4 months.

2. Analysis of the current state

Analyzing the current state forms the core of the project analysis phase. It is an important step
to thoroughly understand the existing system. This process involves studying and identifying
the various imperfections of the current system and proposing appropriate solutions.

2.1. Description of the current state

Before this project, Topnet lacked a dedicated platform for its customers to conveniently
manage their accounts, pay bills, or request services online. As a result, customers had to rely
on traditional methods, such as phone calls or in-person visits, which could be time-
consuming and inefficient.

This absence of an online portal limited Topnet's ability to provide timely assistance and
tailored services to its customers, potentially leading to frustrations and delays in addressing
their needs.

2.2. Criticizing the current state

The absence of a customer portal meant that Topnet missed out on significant opportunities to
modernize its service delivery and improve customer satisfaction. Without a centralized
platform for online interactions, customers were forced to navigate through multiple channels,
leading to confusion and inefficiencies.

This lack of a digital presence also hindered Topnet's ability to gather valuable insights into
customer preferences and behavior, limiting its capacity to personalize services and anticipate
customer needs proactively. Overall, the absence of a customer portal represented a missed
opportunity for Topnet to enhance its competitiveness and strengthen its relationship with its
customer base.

5
 2.3. The proposed solution

Topnet has proposed that we focus on developing a comprehensive web application for their
customer portal. This application will be fast, responsive, and prioritize user experience,
ensuring a smooth journey for users. It will serve as a one-stop destination for customers to
manage their accounts, pay bills, request services, and submit support tickets conveniently
online. By leveraging modern web technologies and focusing on delivering a seamless user
experience, the application will foster stronger customer loyalty and satisfaction.
Additionally, the new portal will enable Topnet to streamline its internal processes, improve
service efficiency, and gather valuable customer insights. Overall, this solution represents a
significant step forward in Topnet's journey towards delivering exceptional customer
experiences and maintaining its competitive edge.

3. Methodology and Modeling Language

Project management methodology is defined as a system of methods and principles that can
help standardize processes, establish a common language, and understand how to manage the
lifecycle of a project. It enables all stakeholders to work effectively together, following
clearly defined rules to minimize duplication of efforts and increase the project's impact.

Therefore, in our project, we followed a meticulous methodological design, which allowed us

to better analyze and manage the various stages of implementing the application.

3.1. Agile Methods

The choice of an appropriate methodology depends on various parameters such as the
project's characteristics and constraints. Therefore, we chose to adapt an incremental and
iterative method rather than a traditional method since the process of realizing our project was
unpredictable. Among iterative methods, Agile methods are widely used worldwide. An Agile
method is based on a simple idea: "Planning the entirety of your project in great detail before
developing it is counterproductive."

6
It recommends setting short-term goals. The project is divided into several sub-projects. Once
the goal is achieved, we move on to the next one until the final objective is accomplished.
This approach is more flexible because it is impossible to predict and anticipate everything; it
allows room for unforeseen events and changes.

Another important point: the Agile method relies on a privileged relationship between the
client and the project team. Since client satisfaction is the priority, total involvement of the
team and responsiveness to changes are essential. Dialogue is privileged. The client validates
each stage of the project, so it is necessary to consider the evolution of their needs.
Adjustments are made in real-time to meet their expectations.

With the Agile approach, nothing is set in stone. The project team must be able to constantly
reassess themselves and continually seek to evolve.

There are several Agile methods, and it is not about choosing the best method among those
available. For our project, we opted for an Agile method, more specifically, SCRUM.

3.2. Presentation of the SCRUM Methodology

The most famous of project management methodologies derived from Agile is "Scrum,"
named after the "scrum" formation in rugby. The project manager is thus called the "SCRUM
Master."

This approach is organized around short cycles, commonly referred to as iterations. In Scrum
terminology, an iteration is called a "sprint." At the beginning of each new sprint, the project
team gathers to list the tasks to be executed. This list is called the "sprint backlog."

The entire process is based on product development logic. This explains why the Scrum
methodology revolves around specific roles, such as the Product Owner. Scrum meetings are
held daily. These are short periods of exchange during which project team members
communicate about their progress and challenges. [1]

7
 Figure 1.4 : SCRUM process

3.3. Unified Modeling Language (UML)

The Unified Modeling Language (UML) is designed to be a
common, visually rich, and semantically and syntactically rich
modeling language. It is intended for the architecture, design,
and implementation of complex software systems, both in terms
of their structure and behavior. UML has applications that extend
beyond software development, including process flows in industry. It resembles blueprints
used in other domains and consists of various types of diagrams. Overall, UML diagrams
describe the boundary, structure, and behavior of the system and the objects within it.

UML is not a programming language, but there are tools that can be used to generate code in
multiple languages from UML diagrams. UML has a direct relationship with object-oriented
analysis and design. [2]

Conclusion
This chapter provided me with an overview of the project framework and the appropriate
methodology for the proposed solution. The next step will be devoted to a detailed study of
the project.

8
 Chapter 2
Study and Project Planning

9
Introduction
In this chapter, we will first present the identification, structure, and planning of the project.
Secondly, we will detail the work environment, the development languages used, and the
architecture of the system.

1. Requirements Specification
This phase involves understanding the context of the system. It is about determining the most
relevant actors and functionalities.

1.1. Identification of Actors

To develop our project, we were able to identify the following actors:

Figure 2.1: Identification of Actors

Customers can securely authenticate and access features such as updating contact info,
viewing bills, paying bills, managing contracts, submitting support tickets, and tracking
requests, including migrations and complaints. They can also participate in surveys, offer
suggestions, and view summaries on the dashboard.

1.2. Functional Requirements

These are the functionalities to be provided by the platform. They are the needs specifying the
input/output behavior. The platform must allow for:

10
For the customer:

 Authenticate
 Update contact information
 View current and past bills
 Pay bills
 Manage contracts
 Create and manage email accounts
 Submit support tickets
 Track the status of support requests
 Submit complaints
 Track the status of complaints
 Submit a request to migrate to a different service plan
 Track the status of migration requests
 Request the transfer of a service to a new address
 View the history of line transfer requests
 Provide suggestions for service improvements
 View the history of the suggestions made
 Participate in satisfaction surveys
 View a summary of the account on the dashboard

1.3. Non-Functional Requirements

These are the features that characterize the system. They are requirements related to
performance and design type. Therefore, this platform must necessarily meet the following
needs:

→ Reliability: It must function consistently without errors and must be satisfactory.

→ Performance: Ambiguities must be signaled by well-organized error messages to guide
the user effectively and familiarize them with our platform.
→ Security: It must prioritize the confidentiality of personal data.
→ Usability: It must be easy to use; it should offer user-friendly, simple, and ergonomic
interfaces.

11
2. Structure and Project Planning
2.1. Product Backlog
The product backlog is the list of expected features of a product. More precisely, beyond this
functional aspect, it contains all the elements that will require work for the team. The items
are prioritized, allowing the definition of the implementation order. [3]
To estimate the complexity of our user stories, we used:

• 2: Easy
• 3: Simple
• 5: Normal
• 8: Difficult
• 13: Very difficult

The following table summarizes the product backlog of the platform:

Table 2.1: Product Backlog

ID User stories Priority Complexity
PFE-1 As a customer, I want to log in to my account. 1 5

As a customer, I want to view and update my

PFE-2 contact information.
2 3

As a customer, I want to reset my forgotten

PFE-3 password.
3 3

As a customer, I want to view my current and past

PFE-4 bills.
4 5

As a customer, I want to pay my bills online using

PFE-5 a credit card or bank transfer.
5 8

As a customer, I want to receive an email

PFE-6 confirmation after making a payment.
6 3

As a customer, I would like to manage my

PFE-7 contracts.
7 5

As a customer, I want to create and manage email

PFE-8 accounts associated with my service.
8 5

12
 As a customer, I want to submit support tickets
PFE-9 when I have issues.
9 5

As a customer, I want to track the status of my

PFE-10 support request. 10 3

As a customer, I want to submit a complaint if I

PFE-11 am dissatisfied with the service. 11 5

As a customer, I want to track the status of my

PFE-12 complaint. 12 3

As a customer, I want to submit a request to

PFE-13 migrate to a different service plan. 13 5

As a customer, I want to track the status of my

PFE-14 migration request. 14 3

As a customer, I want to request the transfer of

PFE-15 my service to a new address. 15 5

As a customer, I want to view the history of my

PFE-16 line transfer requests. 16 3

As a customer, I want to provide suggestions for

PFE-17 service improvements. 17 3

As a customer, I want to view the history of the

PFE-18 suggestions I have made. 18 3

As a customer, I want to participate in satisfaction

PFE-19 surveys. 19 3

As a customer, I want to view a summary of my

PFE-20 account on the dashboard. 20 5

Total 83

2.2. Sprint Planning

The sprint planning meeting is one of the most important Scrum activities as it defines the
pace of the entire project and helps in executing the various sprints effectively. During this
meeting, we discuss our work plan, which is distributed over a four-month cycle, and each
sprint is estimated to take between two to four weeks.

13
 Figure 2.2 : Theoretical Sprint Estimation

2.3. Global Use Case Diagram

A use case diagram visually represents use cases. It is the primary diagram that ensures the
relationship between the user and the objects that the system implements.

A use case is used to define the behavior of a system or the semantics of any other entity
without revealing its internal structure. Each use case specifies a frequency of action,
including variants that the entity performs by interacting with the entity's actors. The
responsibility of a use case is to specify a set of instances, where an instance of a use case
represents a sequence of actions that the system performs and provides an observable result
for the actor.

14
 Figure 2.3: Global Use Case Diagram

3. Development environment and technical choice

3.1. Development Environment
To set up this application, I used a development environment that ensured the smooth
implementation phase. This environment includes both hardware and software tools.

3.1.1. Hardware Environment

For the development of the platform, I used the following hardware:

15
 Table 2.2: Description of the Development Machine

Unit Characteristics
Device MSI GF thin 11SC
11th Gen Intel® core™ i5-11400H
CPU
@2.70GHz
Laptop RAM 16GB
OS Windows 10
SSD 512GB

3.1.2. Software Environment

The software tools used for developing the platform are:

Windows11: It is a major version of the Windows operating system

developed by Microsoft, built on the Windows NT kernel version 10.
Windows 11 was announced at the Microsoft Event on June 24, 2021.

GitHub: It is a web-based hosting service for version control using Git.

It offers paid professional accounts as well as free accounts for open-
source projects. The site also provides access control and collaboration
features such as bug tracking, feature requests, task management, and a
wiki for each project.

16
 Visual Studio Code: It is an open-source, free, and cross-platform text
editor (Windows, Mac, and Linux) developed by Microsoft. Primarily
designed for application development with JavaScript, TypeScript, and
Node.js, the editor can adapt to other languages thanks to a well-
supplied extension system.

Mailtrap: It is a service that provides developers with a solution for

managing emails sent by an application in a test environment. You can
then view each email in detail (HTML, text, source code) and verify
that everything is correct in the construction of your emails. [4]

Postman: It is an application for testing APIs, created in 2012 in

Bangalore to address a problem of shareable API testing.

Visual Paradigm Online Diagrams: It is a UML CASE

tool that supports UML 2, SysML, and Business Process
Modeling Notation (BPMN) from the Object Management
Group (OMG). In addition to modeling support, it provides
report generation and code engineering capabilities, including code generation. It can reverse
engineer diagrams from code and provide round-trip engineering for various programming
languages.

3.2. Technical Choices

In this section, we will list the various development tools used for the implementation of the
application. The choice is based on their ability to provide results that meet our needs.
Therefore, the development of the platform was carried out using the following tools:

17
 Laravel 8: It is an open-source web framework written in PHP
following the model-view-controller (MVC) architectural pattern and
fully developed in object-oriented programming. Laravel is distributed
under the MIT license, with its sources hosted on GitHub. [5]

MongoDB: It is a document-oriented database management system,

scalable across any number of machines and does not require a
predefined data schema. It is written in C++. The server and tools are
distributed under the SSPL license, drivers under the Apache license,
and documentation under the Creative Commons license. It is part of
the NoSQL movement.

ReactJS: It is a free JavaScript library developed by Facebook since

2013. The main goal of this library is to facilitate the creation of single-
page web applications by creating components that depend on state and
generate an HTML page (or portion) with each state change.

Bootstrap 5: It is a collection of tools useful for designing (graphics,

animation, page interactions in the browser, etc.) websites and web
applications. It is a set that contains HTML and CSS codes, forms,
buttons, navigation tools, and other interactive elements, as well as
optional JavaScript extensions.

4. Architecture of the System

4.1. MVC Architecture
It is a software architecture pattern intended for highly popular graphical interfaces for web
applications. Its main interest is the separation of data (model), display (view), and actions
(controller), which ensures architectural clarity and simplifies the task of the developer
responsible for maintaining and improving the project. The roles of the 3 entities are as
follows:

18
 Model: The model represents the core of the application: data processing and interaction
with the database. It describes the data manipulated by the application, manages them, and is
responsible for their integrity. The database will be one of its components. The model
includes standard methods for updating this data (insertion, deletion, value change). It also
provides methods to retrieve this data. The results returned by the model are not concerned
with the presentation.
 View: Interfaces with the user. Its first task is to present the results returned by the model,
and its second task is to receive any user action. These different events are sent to the
controller. The view does not perform processing; it simply displays the results of the
processing performed by the model and interacts with the user.
 Controller: The controller is responsible for managing synchronization events to update
the view or model and synchronize them. It receives all user events and triggers the actions to
be performed.

Laravel is a framework that follows the MVC architecture, but in this project, it only manages
the model (M) and the controller (C), and React JS only manages the application interface
considered as the view (V) in MVC.

4.2. Application Functionality

 Server-side (Laravel): Creates REST APIs.

 REST APIs are used to perform CRUD operations on a database.
 Client-side (ReactJS) consumes REST APIs using HTTP methods such as GET,
POST, PUT, and DELETE.
 REST APIs return data in JSON format to the client-side.

The image below illustrates the application's functionality:

19
 Figure 2.4: Application Functionality

5. Release Planning

Table 2.3 : Release Planning

Sprint 1 Sprint 2 Sprint 3
From 12/02/2024 to From 12/03/2024 to From 12/04/2024 to
11/03/2024 09/04/2024 10/05/2024
PFE-13 PFE-14 PFE-15
PFE-1 PFE-2 PFE-3 PFE-4 PFE-7 PFE-8 PFE-9 PFE-10
PFE-16 PFE-17 PFE-18
PFE-5 PFE-6 PFE-11 PFE-12
PFE-19 PFE-20
Complexity : 27 Complexity : 26 Complexity : 30

Conclusion
In this chapter, we have defined the functional and non-functional requirements, the product
backlog, the development environment, the system architecture, as well as the release
planning.

20
 Chapter 3: Sprint 1
Account Access, Profile Management & Billing
Management

21
 Introduction
In this chapter, we will present the details of the implementation of the first sprint, starting
with the needs analysis and design used in the development, and concluding with a
presentation of the interfaces for the first part of the completed platform.

1. Needs Analysis
1.1. Sprint Backlog
The sprint backlog is a list of tasks that the Scrum team aims to complete during a project
sprint. This work plan is developed during a sprint planning session and is based on the items
in the product backlog. Designing a sprint backlog clearly indicates to the Scrum team which
tasks to focus on during each sprint to avoid any deviation from the objectives. [6]

The table below lists all the functionalities that will be developed during the first sprint:

Table 3.1: First Sprint Backlog

ID Theme ID User stories Priority
As a customer, I want to log in to my
1.1 High
account.
1 Account Access
As a customer, I want to reset my
1.2 High
forgotten password.
As a customer, I want to view my
2.1 Medium
contact information.
2 Profile Management As a customer, I want to update my
2.2 Medium
contact information.
As a customer, I want to view my
3.1 High
current and past bills.
As a customer, I want to download my
3.2 Medium
3 Billing Management bills in PDF format.
As a customer, I want to pay my bills
3.3 online using a credit card or bank High
transfer.

22
 1.2. Use Case Diagram for the First Sprint
To make the view of the functionalities and their ordering clearer and easier, I illustrate the
functional specification with a use case diagram that defines the relationship between the user
and the objects implemented by the system.

The diagram below presents the system use case for the first sprint:

Figure 3.1: Use Case Diagram for Sprint 1

1.3. Use Case Analysis

1.3.1. Analysis of the "Authenticate" Case

Figure 3.2 : "Authenticate" Use Case Diagram

The textual description shown in Table 3.2 presents the scenario for the "Authenticate" use
case illustrated in Figure 3.2:

23
 Table 3.2: Textual Description of "Authenticate" Use Case

Title Authenticate
Objective Allow customers to access their spaces.
Actors Customer
The customer must enter his customer code and
Pre-condition
password.
Post-condition The customer is authenticated.
1. The customer enters customer code and
password.
Description of the nominal
2. The customer clicks on the “Log in” button.
scenario
3. The system checks the data entered.
4. The system directs the actor to his space.
1. If the customer forgets to enter the required
fields, the system will display an error message
prompting the user to complete the missing
fields.
Alternative Scenario Description 2. If the customer code or captcha code are not
correct, the system displays an error message.
3. If the customer fails to enter the correct login
credentials after 3 attempts, the system will
block the user from attempting to log in for one
minute.

1.3.2. “Reset Forgotten Password” case analysis

Figure 3.3: “Reset forgotten password” Use case

The textual description shown in Table 3.3 presents the scenario for the "Reset forgotten
password" use case illustrated in Figure 3.3:

24
 Table 3.3: Textual Description of "Reset forgotten password" Use Case

Title Reset forgotten password

Objective Allow customers to reset their forgotten password.
Actors Customer
Pre-condition The customer must enter their E-mail address.
Post-condition The password is modified.
1. The customer clicks on the “Forgot Password?” link.
2. The customer enters their email address.
3. The system checks the entered email address.
4. Customer clicks on “Send”.
Description of the nominal
5. The system sends a link to retrieve the password.
scenario
6. Customer clicks on the link.
7. The customer enters their new password.
8. The system displays a success message.
9. System directs the user to authentication page.
1. If the customer forgets to enter the required fields, the
system will display an error message prompting the user
to complete the missing fields.
Alternative Scenario
2. If the entered email address is incorrect, the system
Description
displays an error message.
3. If new passwords entered do not match, the system
displays an error message.

1.3.3. Analysis of the case “Manage profile”

Figure 3.4: « Manage profile » Use case

The textual description shown in Table 3.4 presents the scenario for the "Manage profile" use
case illustrated in Figure 3.4:

25
 Table 3.4: Textual Description of "Manage profile" Use Case
Title Manage profile(View/Update)
Objective Allow customers to update their contact information.
Actors Customer
Pre-condition The actor must access their profile.
Post-condition The profile is updated.
1. The customer clicks on any chosen field.
Description of the nominal 2. The customer enters new information
scenario 3. The customer clicks on “modify”.
4. The system displays a success message.
Alternative Scenario If any field is empty, the system displays an error message.
Description

1.3.4. Analysis of the case “Manage bills”

Figure 3.5: «Manage bills» Use case

The textual description shown in Table 3.5 presents the scenario for the "Billing
management" use case illustrated in Figure 3.5:

Table 3.5: Textual Description of “Manage bills” Use Case

Title Manage bills(View/Pay bills)
Objective Allow customers to pay their bills.
Actors Customer
Pre-condition The customer must access their billing section.
Post-condition The bills have been paid.
1. The customer clicks on “Payment”.
Description of the 2. The system displays the payment page.
nominal scenario 3. The customer fills the form.
4. The customer clicks on” Pay”.

26
 5. The system displays a success message.
6. The bill status changes to “paid”.
Alternative Scenario If any of the payment fields are incorrect, the system displays an
Description error message.

2. Design
In this section, we will present the class diagram and the detailed sequence diagrams for the
first sprint.

2.1. Class Diagram for the First Sprint

The class diagram is one of the most useful types of UML diagrams, as it clearly describes the
structure of a particular system by modeling its classes, attributes, operations, and the
relationships between its objects. [7]

The figure below represents the class diagram for the first sprint:

Figure 3.6 : Class diagram for the first sprint

27
 2.2. Detailed Sequence Diagrams
To outline the communications between the actors and the components of the sprint, we have
detailed a few use cases below along with their sequence diagrams.

 Authenticate

Figure 3.7 : Sequence Diagram "Authenticate"

28
 Reset forgotten password

Figure 3.8: Sequence Diagram "Reset forgotten password"

 Changer le mot de passe lors de la première connexion

Figure 3.9 : Sequence Diagram "Update profile"

29
 Paybills

Figure 3.10 : Sequence Diagram "Paybills"

3. Implementation and Testing

2.1. Implementation
The implementation phase, or "coding," involves developing the user stories addressed in the
first sprint. Therefore, we will focus on showcasing a few interfaces due to the large number
of product parameters we have implemented.

30
 Figure 3.11 : Login Interface

In this login interface, customers are prompted to enter their unique customer code and
password to gain access to their individual accounts.

Figure 3.12 : Password Recovery Email Sending Interface

31
This interface streamlines the password reset process by allowing users to request a reset via
their email addresses. Upon submission, a password reset link is promptly dispatched to the
provided email, as illustrated in the accompanying figures. This link grants users the ability to
update their password, ensuring seamless account access.

Figure 3.13 : Reset Password Notification Interface

Figure 3.14 : Reset Password Interface

32
 Figure 3.15 : Update Contact Information Interface

This interface empowers cutomers to effortlessly update their contact information. cutomers
can modify essential details such as their address, phone number and email. By ensuring that
their contact information is accurate and up to date.

33
 Figure 3.16 : Bills List Interface

Figure 3.17 : Payment Interface

These interfaces provide users with a convenient platform to manage their bill payments
efficiently. Users can securely review outstanding bills, select payment methods, and submit
payments seamlessly.

34
 3.2. Unit Testing
Unit testing ensures the correct functionality of a specific part of an application. Its objective
is to isolate the behavior of the code segment being tested from external factors and verify
that it meets the expected outcomes.
Therefore, we used the open-source unit testing software Postman to test certain cases.

 Unit Testing for the "Authenticate" Use Case

In the case of success, the test should return a message indicating that the result is positive.

Figure 3.18 : Result interface of the "Authenticate" test

Conclusion
Throughout this chapter, we presented the product backlog, as well as the requirements
analysis, design, and implemented interfaces. In the following chapter, we will present the
second sprint.

35
 Chapter 4: Sprint 2
Contracts Management, Email Account
Management, Support & Complaints
Management

36
Introduction
In this chapter, we will present the details of the implementation of the second sprint, starting
with the requirements analysis and the design used in the development, and ending with a
presentation of the interfaces for the second part of the completed platform.

1. Needs Analysis
1.1. Sprint backlog
The table below summarizes all the features that will be developed during the second sprint:

Table 4.1: Backlog for the second sprint

ID Theme ID User stories Priority
As a customer, I would like to view my
1.1 High
contracts.
Contracts
1 As a customer, I would like to activate additional
Management
1.2 features or services by purchasing mini Medium
contracts.
As a customer, I want to view my email accounts
2.1 Medium
Email Account associated with my service.
2
Management As a customer, I want to create email accounts
2.2 High
associated with my service.
As a customer, I want to submit support tickets
3.1 High
when I have issues.
As a customer, I want to track the status of my
Support and 3.2 Medium
support request.
Complaints
3 As a customer, I want to submit a complaint if I
Management 3.3 High
am dissatisfied with the service.
As a customer, I want to track the status of my
3.4 Medium
complaint.

1.2. Use Case Diagram for the Second Sprint

The diagram below presents the system use case at the second sprint level:

37
 Figure 4.1: Use Case Diagram for the Second Sprint

1.3. Use Case Analysis

1.3.1. Analysis of the case “Manage contracts”

Figure 4.2: « Manage contracts » Use case

The textual description provided in Table 4.2 outlines the scenario for the "Manage internship
catalog" use case depicted in Figure 4.2.

Table 4.2: The textual description of the "Manage contracts" use case
Manage Contracts (View/Activate Additional
Title
Features/Services)
Enable customers to activate additional features or
Objective
services by purchasing mini contracts.
Actors Customer

38
 Pre-condition The customer must access their contract section.
The additional features or services have been
Post-condition
successfully purchased and activated.
1. The customer clicks on "Options."
2. The system displays the "Options to Activate on
This Contract" page.
3. The customer chooses an option.
4. The customer clicks on "Pay."
Description of the nominal
5. The system displays the payment page.
scenario
6. The customer fills in the required fields and
clicks on "Pay."
7. The system displays a success message
indicating the purchase and activation are
complete.
Alternative Scenario If any of the payment fields are incorrect, the system
Description displays an error message.

1.3.2. Analysis of the case “Manage emails accounts”

Figure 4.3: «Manage emails accounts» Use case

The textual description provided in Table 4.3 outlines the scenario for the « Consulter le
catalogue des stages » use case depicted in Figure 4.3

Table 4.3: The textual description of the “Manage emails accounts" use
case
Manage Email Accounts (View/Create Email
Title
Accounts)
Enable customers to create email accounts
Objective
associated with their service.
Actors Customer
Pre-condition The customer must access their email section.
A new email account is successfully created and
Post-condition
associated with the customer's service.

39
 1. The system displays the "Email Accounts"
page.
2. The customer clicks on "Add New Email."
3. The system displays the email account
creation form.
Description of the nominal scenario
4. The customer fills in the required fields.
5. The customer clicks on "Send."
6. The system processes the request and
displays a success message confirming the
creation of the new email account.
If any of the required fields are empty, the system
Alternative Scenario Description displays an error message prompting the customer
to fill in all required fields before proceeding.

1.2.3. Analysis of the case “Submit support tickets”

Figure 4.4: «Submit support tickets» Use case

The textual description provided in Table 4.4 outlines the scenario for the «Submit support
tickets» use case depicted in Figure 4.4.

Table 4.4: The textual description of the “Submit support tickets" use case
Title Manage Support Tickets
Enable customers to submit support tickets when
Objective
they have issues.
Actors Customer
The customer must access their support ticket
Pre-condition
section.
A new support ticket is successfully submitted
Post-condition
and processed.
1. The system displays the support ticket
page.
2. The customer clicks on "Add New
Description of the nominal scenario
Ticket."
3. The system displays the ticket
submission form.

40
 4. The customer fills in the required fields.
5. The customer clicks on "Send."
6. The system processes the request and
displays a success message confirming
the submission of the support ticket.
If any of the required fields are empty, the
system displays an error message prompting the
Alternative Scenario Description
customer to fill in all required fields before
proceeding with the ticket submission.

1.2.4. Analysis of the case “Submit complaints”

Figure 4.5: «Submit complaints» Use case

The textual description provided in Table 4.4 outlines the scenario for the «Submit
complaints» use case depicted in Figure 4.4.

Table 4.5: The textual description of the “Submit complaints" use case
Manage Complaints (View/Submit
Title
Complaints)
Enable customers to submit a complaint if
Objective
they're dissatisfied with the service.
Actors Customer
The customer must access their complaints
Pre-condition
section.
A new complaint is successfully submitted and
Post-condition
processed.
1. The system displays the complaints page.
2. The customer clicks on "Submit New
Complaint."
3. The system displays the complaint
Description of the nominal scenario submission form.
4. The customer fills in the required fields.
5. The customer clicks on "Submit."
6. The system processes the request and
displays a success message confirming

41
 the submission of the complaint.
If any of the required fields are empty, the
system displays an error message prompting the
Alternative Scenario Description
customer to fill in all required fields before
proceeding with the complaint submission.

2. Design
In this section, we will present the class diagram and the detailed sequence diagrams for the
second sprint.

2.2. Class Diagram for the second Sprint

The class diagram is one of the most useful types of UML diagrams, as it clearly describes the
structure of a particular system by modeling its classes, attributes, operations, and the
relationships between its objects. The figure below represents the class diagram for the second
sprint:

Sprint 1 Sprint 2

Figure 4.6: Class diagram for the second sprint

42
 2.2. Detailed Sequence Diagrams
To outline the communications between the actors and the components of the sprint, we have
detailed a few use cases below along with their sequence diagrams.

 Submit complain

Figure 4.7 : Sequence Diagram "Submit complain"

3. Implementation and Testing

3.1. Implementation
In this phase, we will present some interfaces related to the second sprint, given the large
number of product parameters that we have implemented.

43
 Figure 4.8 : Contracts List Interface

Figure 4.9 : Mini Contract Purchase Interface

These interfaces empowers customers to purchase and manage mini contracts efficiently.
Users can explore available contracts and complete purchases seamlessly.

44
 Figure 4.10 : Email Account Management interface

This interface offers customers a centralized platform for effective management of their email
accounts. Here, they have the ability to effortlessly create new email addresses.

Figure 4.11 : Complaint Submission Interface

45
This interface empowers customers to voice their dissatisfaction with the service provided.
Customers can submit complaints detailing their concerns, ensuring that their feedback is
heard and addressed promptly.

3.2. Unit Testing

 Complaint Submission Log Test

In case of success, the conducted test should return a message displaying the history of
complaints made.

Figure 4.12 : Complaint Submission Log Test Interface

Conclusion
Throughout this chapter, we have completed the second sprint, where we presented the
product backlog, as well as the requirements analysis, design, and implemented interfaces.
Therefore, we will study the implementation steps of the final sprint in the next chapter.

46
 Chapter 5: Sprint 3
Service Plan Management, Address Transfer
Requests, Feedback & Dashboard
Enhancement

47
Introduction
In this chapter, I will present the detailed implementation of the third sprint, starting with the
analysis of the requirements and the design used in development, and concluding with a
presentation of the interfaces for the third part of the platform created.

1. Needs Analysis
1.1. Sprint backlog
The table below lists all the features that will be developed during the third sprint:

Table 5.1 : Third Sprint Backlog

ID Theme ID User stories Priority
As a customer, I want to submit a
1.1 request to migrate to a different High
1 Service Plan Management service plan.
As a customer, I want to track the
1.2 Medium
status of my migration request.
As a customer, I want to request the
2.1 transfer of my service to a new High
2 Address Transfer Requests address.
As a customer, I want to view the
2.2 Medium
history of my line transfer requests.
As a customer, I want to provide
3.1 suggestions for service Low
improvements.
As a customer, I want to view the
3.2 history of the suggestions I have Low
Feedback & Dashboard
3 made.
Enhancement
As a customer, I want to participate
3.3 Low
in satisfaction surveys.
As a customer, I want to view a
3.4 summary of my account on the High
dashboard.

1.2. Use Case Diagram for the Third Sprint

The diagram below illustrates the system's use case at the level of the third sprint:

48
 Figure 5.1: Use Case Diagram for the Third Sprint

1.3. Analysis of Use Cases

1.3.1. Analysis of the "Submit a request to migrate to a

different service plan" Use Case

Figure 5.2: Use Case Diagram " Submit a request to migrate to a different
service plan ' Files

The textual description represented in Table 5.2 illustrates the scenario for the "Submit a
request to migrate to a different service plan" use case depicted in Figure 5.2.

49
 Table 5.2: Textual Description of "Submit a request to migrate to a
different service plan" Use Case
Title Submit a request to migrate to a different service plan
Enable customers to submit a request to migrate to a
Objective
different service plan.
Actors Customer
Pre-condition The customer must access their service plan section.
The request to migrate to a different service plan is
Post-condition
successfully submitted and processed.
1. The system displays the service plan page.
2. The customer clicks on "Change Service Plan."
3. The system displays the service plan migration form.
Description of the nominal
4. The customer fills in the required fields.
scenario
5. The customer clicks on "Submit."
6. The system processes the request and displays a
success message confirming the migration request.
If any of the required fields are empty, the system displays
Alternative Scenario an error message prompting the customer to fill in all
Description required fields before proceeding with the service plan
migration request.

1.3.2. Analysis of the "Provide Suggestions for Service

Improvements" Use Case

Figure 5.3: Use Case Diagram "Provide Suggestions for Service

Improvements"

The textual description represented in Table 5.3 illustrates the scenario for the "Provide
Suggestions for Service Improvements" use case depicted in Figure 5.3.

Table 5.3: Textual Description of "Provide Suggestions for Service

Improvements" Use Case
Title Provide Suggestions for Service Improvements
Enable customers to submit suggestions for service
Objective
improvements.

50
 Actors Customer
Pre-condition The customer must access their suggestions section.
The suggestion for service improvements is successfully
Post-condition
submitted and acknowledged.
1. The system displays the suggestions page.
2. The customer clicks on "Submit Suggestion."
3. The system displays the suggestion submission form.
Description of the nominal 4. The customer fills in the required fields.
scenario 5. The customer clicks on "Submit."
6. The system processes the request and displays a
success message confirming the suggestion has been
received.
If any of the required fields are empty, the system displays an
Alternative Scenario
error message prompting the customer to fill in all required
Description
fields before proceeding with the suggestion submission.

1.3.3. Analysis of the "Participe in satisfaction surveys" Use

Case

Figure 5.4: Use Case Diagram "Participe in satisfaction surveys"

The textual description represented in Table 5.4 illustrates the scenario for the "Provide
Suggestions for Service Improvements" use case depicted in Figure 5.4.

Table 5.4: Description textuelle de cas d'utilisation "Participe in satisfaction

surveys"
Title Participate in the Satisfaction Surveys
Objective Enable customers to participate in satisfaction surveys.
Actors Customer
Pre-condition The customer must access their surveys section.
The satisfaction survey responses are successfully
Post-condition
submitted and recorded.

51
 1. The system displays the satisfaction survey page.
2. The customer selects their responses for the
survey questions.
Description of the nominal
3. The customer clicks on "Send."
scenario
4. The system processes the responses and displays
a success message confirming the survey has
been submitted.
If any required questions are unanswered, the system
displays an error message prompting the customer to
Alternative Scenario Description
complete all required questions before submitting the
survey.

2. Design
In this section, we will present the class diagram and detailed sequence diagrams for the third
sprint.

2.1. Class Diagram of the Third Sprint

The figure below represents the class diagram for the third sprint:

Sprint 1
Sprint 2
Sprint 3

52
Figure 5.5: Class diagram for the third sprint

53
 2.2. Detailed Sequence Diagrams
To outline the communications between the actors and the components of the sprint, we have
detailed a few use cases below along with their sequence diagrams.

 Line transfer request

Figure 5.6 : Sequence Diagram"Line transfer request"

 Send Satisfaction

Figure 5.7 : Sequence Diagram "Send Satisfaction"

54
3. Implementation and Testing
3.1. Implementation
In this phase, we will present some interfaces related to the second sprint, given the large
number of product parameters that we have implemented.

Figure 5.8 : Service Plan Migration Request Interface

This interface facilitates customers in submitting requests to migrate to a different service

plan by providing their current contract and specifying both their current and desired offer.

55
 Figure 5.9 : Line Transfer Request Interface

This interface streamlines the process for customers to request the transfer of their service to a
new address. Customers can provide their current service details and specify the new address
where they want the service transferred.

56
 Figure 5.10 : Service Enhancement Suggestions Interface

This interface empowers customers to contribute valuable suggestions aimed at enhancing our
service. Customers can provide detailed context, specify the subject of their suggestion, and
compose their message to ensure clarity and relevance.

Figure 5.11 : Satisfaction Survey Participation Interface

57
This interface enables customers to actively participate in satisfaction surveys aimed at
enhancing our services. Customers can provide their feedback by responding to specific
questions tailored to measure various aspects of their experience.

3.2. Unit Testing

 Service Plan Migration Request Log

In case of success, the conducted test should return a message displaying the history of
service migrations made.

Figure 5.12 : Service Plan Migration Request Log Interface

Conclusion
In this chapter, I have presented and detailed the various phases of the final sprint. At this
stage, we have successfully designed a functional product.

58
 Conclusion

This report represents the culmination of the work carried out within the company Topnet as
part of our end-of-studies project. It covers the study, as well as the design and development
of a web application for a client portal at Topnet.

The objective of this project is to create a user-friendly interface enabling customers to

manage their accounts, pay bills, request services, and submit support tickets online. Utilizing
modern web technologies, the application enhances customer experience, improves service
efficiency, and streamlines communication with Topnet.

In project management and monitoring, we employed Agile methods and opted for the
SCRUM method based on the sprint principle. These sprints were divided as follows: we
started with user stories and their specifics, followed by the schematization of use case
diagrams related to the functionalities. Then, we described the scenarios' flow, and finally, we
concluded with the design and implementation of the interfaces, followed by testing.

This internship provided us with the opportunity to learn new concepts and discover new
technologies such as React JS and Laravel. We also realized the importance of unit testing to
verify the proper functioning of specific parts of the application.

In general, this internship has been a valuable gift for us, allowing us to take a significant step
into the professional world. We will be able to leverage all the best practices and knowledge
gained from this experience in our future jobs and projects.

59
Bibliography & Webography

https://fr.wikipedia.org/wiki/
[1] https://www.planzone.fr/blog/quest-ce-que-la-methodologie-agile
[2] https://www.lucidchart.com/pages/fr/langage-uml
[3] https://www.aubryconseil.com/post/2009/le-backlog-de-produit/
[4] https://veilleperso.com/mailtrap-gerer-facilement-mails-test-5976
[5] https://www.webandcow.com/technologies/laravel/
[6] https://asana.com/fr/resources/sprint-backlog
[7] https://www.lucidchart.com/pages/fr/diagramme-de-classes-uml

60