Dedications

Without the participation and cooperation of a lot of people, each of whom assisted me
in their own manner and each of whom added a particular touch, this work would not
have been possible.

I want to express my gratitude to all of my friends for their moral support. A huge thank
you to my family, especially my parents, for their emotional support and the thought they
put into the creation of this piece.

I will never forget the sweets and the inspiring words of my dear mother, who is my source
of joy. This work is the result of a will that was made concrete by success.

No devotion to my loving father can adequately convey how much I treasure having him
by my side.

His assistance and advice offer me the strength I need to more successfully face life’s
obstacles. I’m hoping that my modest effort will be able to make up for the sacrifices you
made for me.

I dedicate this project to everyone I adore. I ask God to keep them close to me.

i
Acknowledgement

First of all, I would like to thank Mr. Slim Maaloul, my supervisor and Co-Manager of
the International Smart Business Solution company for accepting me as a trainee under
his supervision in the first place, and for giving me his valuable time in an effort to fully
explain the work that needed to be done and the instructions that needed to be followed
in order to complete the assigned work.

I would also like to express my gratitude for his patience and understanding. I want
to express my gratitude to Mr. Mohamed Amine LIMEM, my ESPRIT teacher and
instructor, for the priceless time he so kindly dedicated to me and for all the good advice
he provided me.

He deserves to know how much his presence was valued, thus I would want to sincerely
thank him for being here.

I also want to express my gratitude to the jury members who agreed to judge my work.

Last but not least, I would want to express my sincere gratitude to my parents for their
assistance because without their help this project would not have been successful.

ii
Contents

Dedications i

Acknowledgement ii

List of Abbreviations 1

General Introduction 2

1 Project Context 4
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Host organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Smart Business Solution . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Fields of Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Theoretical Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Project Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Project Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Problematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Work Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1 Comparison of Methodologies . . . . . . . . . . . . . . . . . . . . . 7
1.5.2 Choice of Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.3 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.3.1 Trello Definition . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.4 Modelling language . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.5 Project Steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.6 Scrum Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

iii
 1.6 Back-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6.2 Global Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Needs Analysis and Specification 14

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Identification of Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Critique of Existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Comparative Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 The Expected needs of the Application . . . . . . . . . . . . . . . . 16
2.3.3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.4 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . 17
2.4 Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Global Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Solution Development 20
3.1 Sprint 1 : Preparing the web Services . . . . . . . . . . . . . . . . . . . . . 20
3.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3 Detailed Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.3.1 Detailed Backend Architecture . . . . . . . . . . . . . . . 22
3.1.4 Used Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.4.1 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.4.2 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.4.3 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . 23
3.1.4.4 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.5 Test and Realization . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Sprint 2 : Mobile Application Development . . . . . . . . . . . . . . . . . . 25
3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iv
 3.2.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Used Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3.1 Choice of Technology . . . . . . . . . . . . . . . . . . . . . 28
3.2.4 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4.1 Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4.2 Dart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4.3 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.5 Mobile Application Architecture . . . . . . . . . . . . . . . . . . . . 30
3.2.5.1 Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.5.2 Detailed Frontend Architecture . . . . . . . . . . . . . . . 31
3.2.6 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.6.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . 32
3.2.6.2 Descriptive Table . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.6.3 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . 33
3.2.7 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Sprint 3 : Web Dashboard Development . . . . . . . . . . . . . . . . . . . 47
3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.3.1 Monitoring Users Use Case Diagram . . . . . . . . . . . . 50
3.3.3.2 Monitoring Users Descriptive Table . . . . . . . . . . . . . 51
3.3.3.3 Project Management Use Case Diagram . . . . . . . . . . 52
3.3.3.4 Project Management Descriptive Table . . . . . . . . . . . 52
3.3.3.5 Bills Management Use Case Diagram . . . . . . . . . . . . 53
3.3.3.6 Bills Management Descriptive Table . . . . . . . . . . . . 54
3.3.3.7 Monitoring Sequence Diagram . . . . . . . . . . . . . . . . 54
3.3.3.8 Projects and Bills Management Sequence Diagram . . . . 56
3.3.4 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.4.1 Web Dashboard Home Page . . . . . . . . . . . . . . . . . 57
3.3.4.2 Users List . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.4.3 The Monthly Sheets of a specific user . . . . . . . . . . . . 58

v
 3.3.4.4 The Daily Sheets of a specific user . . . . . . . . . . . . . 59
3.3.4.5 Projects List . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.4.6 Add Project Interface . . . . . . . . . . . . . . . . . . . . 60
3.3.4.7 Archived Projects . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.4.8 Bill A Project . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.4.9 Bills List . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.4.10 Bill Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4 Sprint 64

General Conclusion 65

Summary 66

References 67

vi
List of Figures

1.1 The logo of the Smart Business Solution Company SBS . . . . . . . . . . . 4

1.2 Scrum Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Global Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Internal Software Dynamics Nav . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Global Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 NodeJS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 NodeJs Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 MongoDB Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Visual Studio Code Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Postman Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Postman Request Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7 Flutter Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8 Dart Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Android Studio Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10 Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11 Flutter Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.12 Daily Sheet Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.13 Sign Up And Login Sequence Diagram . . . . . . . . . . . . . . . . . . . . 34
3.14 User Insert Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.15 Login Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.16 Welcome Page Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.17 Sign UP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

vii
3.18 Forgot Password Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.19 Monthly Sheets Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.20 Sort Monthly Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.21 Insert A Daily Sheet UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.22 Pick A Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.23 Type of Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.24 Error Message 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.25 Success Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.26 Monthly Sheet Added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.27 List of Daily Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.28 Daily Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.29 Day Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.30 Picking a Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.31 Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.32 Chat Bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.33 Users Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.34 Users Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.35 Add Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.36 Display Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.37 Monitoring Users Use Case Diagram . . . . . . . . . . . . . . . . . . . . . 50
3.38 Project Management Use Case Diagram . . . . . . . . . . . . . . . . . . . 52
3.39 Bills Management Use Case Diagram . . . . . . . . . . . . . . . . . . . . . 53
3.40 Monitoring Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.41 Projects and Bills Management Sequence Diagram . . . . . . . . . . . . . . 56
3.42 Dashboard Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.43 Dashboard List of Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.44 The Monthly Sheets of a user . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.45 The Daily Sheets of a user . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.46 Projects List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.47 Add a Project in Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.48 Archived Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.49 Bill A Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

viii
3.50 Bills List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.51 Bill Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

ix
List of Tables

1.1 Methodology Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 SBS Monitor Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Technology Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Descriptive Table for User Use Case Diagram . . . . . . . . . . . . . . . . 32
3.5 Sprint 3 Backlog Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6 Monitoring User Descriptive Table . . . . . . . . . . . . . . . . . . . . . . 51
3.7 Project Management Descriptive Table . . . . . . . . . . . . . . . . . . . . 52
3.8 Bills Management Descriptive Table . . . . . . . . . . . . . . . . . . . . . . 54

x
List of Abbreviations

IT : Information Technology

SBS : Smart Business Solution

ERP : Enterprise resource planning

SME : Small-to-medium Enterprise

NAV : Navision

CRM : Customer Relationship Management

UML : Unified Modeling Language

IDE : Integrated Development Environment

IT : User Interface

I/O : Input/Output

API : Application Programming Interface

1
General Introduction

Nowadays, monitoring plays a vital role in the success of any business organization.
Indeed, to optimize your company’s performance, it is crucial to accurately measure the
quality and defect levels of your consultants and employees.
The data gathered by monitoring identifies any gaps or problems that need resources to be
fixed, and allows the company to assess its compatibility with other organizations in terms
of values and methods of work which will be a big help while deciding to work on a project.

Most companies would need a software to keep track of their current projects and workers.
Therefore, they often want to use their own products.
In this regard, a new innovative technology called "Flutter", a framework which exposes
new bases to answer all its problems since it is cross-platform.

In this perspective, our end-of-studies project is to design and develop a mobile application
(SBS Monitor) and a web dashboard that offers services like daily sheets management,
monthly sheets management, projects management, billing projects and also a live chat
bot that helps answer the most frequently asked questions.

This following report is divided into three chapters:

• Project Context: This section focuses on the presentation of the host organization
while placing the project in its context, we also demonstrated the Theoretical Study,
the work methodology and at the end we finished it off with the product backlog.

2
• Needs Analysis and Specification: The second chapter is dedicated to the prelimi-
nary study such as the identification of actors and the needs of the application.

• Solution Development: This is the third chapter, it focuses on the finalization of our
product that meets the client’s specifications, It is divided by three big parts, the
first one is the preparation of our web services, the second part is the development
of our mobile application whereas the third one is the development of the web
dashboard.

The present project was realized following the "Agile Scrum" approach.

3
Chapter 1

Project Context

1.1 Introduction
The first chapter will focus on the general context of the project. We’ll start by intro-
ducing the host organization and its various fields of activity, followed by the problematic
and the proposed solutions.

1.2 Host organization

In this section we are going to present our host organization, in which the graduation
project will be carried out, the company’s name is Smart Business Solution.

1.2.1 Smart Business Solution

SBS (Smart Business Solution) is an IT Engineering and Services Company special-

ized in software engineering and the implementation and establishment of ERP Microsoft
Dynamics NAV. They are also partners of Microsoft.

Figure 1.1: The logo of the Smart Business Solution Company SBS

4
 The company proposes to provide installation, implementation and integration of busi-
ness management solutions to help growing companies meet their operational challenges,
financial, regulatory and technical thanks to a proven process of discovery, analysis, de-
sign and delivery and through multiple technology solutions such as ERP, CRM, Business
Intelligence and Office Productivity to create, deploy and take care of innovative systems
in their data center or in the cloud.

1.2.2 Fields of Activity

The main activities of SBS are: Integration of ERP enterprise management solutions,
IT development and outsourcing.

• The integration of management solutions is proposed according to the size of the

companies and their needs: ERP/ Dynamics Nav and Business Central for
medium and large industrial enterprises and the sage management solution for
SME. The integration of enterprise management solutions includes: Consultancy in
company organisation and management, assistance in the implementation of ERP
following a certified methodology and any specific development during the integra-
tion of ERP.

• IT development includes the development of turnkey solutions from specifications for

European partners and customers in high-tech environments.(JAVA,L4G,.Net).

• Outsourcing allows companies to streamline their IT investments while guarantee-

ing the reliability of the information, the security of the data and the availability
of the systems put in place (hardware and software). It is divided into: System
Engineering, Consulting, Hardware and Software Support and Administration of
the various commercial software packages.

1.3 Theoretical Study

The purpose of this part is to give a definition of the framework we chose, its advantages
as well as its basic principles and certain fields of application.

5
1.4 Project Presentation
In this section, we will present our project starting with our objectives, problematic and
the proposed solutions.

1.4.1 Project Objective

• Cover the field of activity for the company while ensuring personal data security.

• Organization of work with client companies.

• Have a monthly sheet at the end of each month to track the work of consultants.

• Generating statistical documents for the billing department and the human resources
department to monitor the employees performances.

1.4.2 Problematic

Each company should monitor its system internally and ensure their performance
monitoring in order to anticipate the various risks that may arise and keep track of their
employees. SBS Group is an IT service provider operating in the digital transformation of
companies and in order to maintain its consistency, the quality and defect levels of their
consultants and staff must be precisely measured. The information gathered through
monitoring identifies any gaps or issues that require resources to be fixed. It also enables
the business to evaluate how well it aligns with other organizations in terms of values and
working practices, which will be very helpful when deciding whether or not to take on a
project. And as a part of the management of its client projects and the management of
the response time of its collaborators, it needs a solution that unifies and facilitates the
supervising of their consultants and the billing of these projects.

1.4.3 Proposed Solution

SBS suggested that we find a solution in order to take advantage of its features and
modules to achieve our final goal. And together, we came up with the idea of a mobile
and web application dedicated to planning, assignment, billing, time management, project
management, human resources management.
The following application will enable the company to:

6
 • Have their own monitoring product to secure their private data and expand their
network.

• Monitor all of their employees.

• Have the full list of organizations they work with and the list of projects they have
in their disposals.

• Have the ability to bill said projects.

1.5 Work Methodology

The increasing complexity of computer systems has led designers to become more inter-
ested in methods. A method gives the concepts to describe the product and the rules of
methodological conduct for its production with reasonable quality and efficiency. It is the
steps that will constitute the tools which we will use to organize the work associated with
the project.

1.5.1 Comparison of Methodologies

In the table 1.1 below we will make a comparative study of the most known agile
methodologies.

Table 1.1: Methodology Comparison

Agile
Method- Advantages Disadvantages
ologies
- Iterative.
- There is a need to be extremely
- Low Costs: A cost-saving approach
rigorous on the implementation and
for a project.
monitoring.
- Flexible and Adaptive : while it is
- The difficulty of implementation
SCRUM very difficult to accurately define the
for complex projects and large-scale
requirements for the solution of the
enterprises.
project, adaptivity is very important
- The documentation tends to be less
to ensure that the client is satisfied
elaborate and detailed.
with the end product.

7
 - Expensive.
- Iterative
- Team members must be experts in
- It takes less time to integrate as
their field when developing software
the integration process progresses
for this methodology.
through the software development
- The process of developing is disor-
life cycle and also because of the re-
RUP ganised and overly complicated.
usability of the components.
- When it comes to big and compli-
- A complete methodology in and
cated projects, it will only add to the
of itself, focusing on accurate doc-
confusion and cause other issues dur-
umentation and sketches for typical
ing the testing stages throughout the
projects.
software development process.
- Iterative.
- It is more code-based than design-
- It reduces the costs and time it
based which doesn’t help in sales in
takes to to set the project in motion.
the software industries because the
- Constant feedbacks, you can make
design is an important aspect to at-
XP any change at any given moment de-
tract customers.
pending on the suggestions.
- It fails to measure code quality as-
- The entire process is apparent and
surance which may cause faults in
accountable.
the original code.
- Very simple to implement.

1.5.2 Choice of Method

Convinced that there are no bad methods, but just an unsuitable choice for one project
or another, the choice of Scrum as a steering methodology for our project was based on the
strengths of the latter which are: Flexibility and responsiveness. Scrum brings together
both theoretical and practical aspects and is very close to reality which minimizes risks.
Extremely adaptable to change thanks to short iterations.

Figure 1.2: Scrum Cycle

8
1.5.3 Trello

To help manage the project, we decided to use Trello.

Figure 1.3: Trello

1.5.3.1 Trello Definition

Trello is a collaborative work management app designed to track team projects, highlight
tasks underway, show who they are assigned to, and detail progress towards completion.
At its core, Trello relies on the principles of Kanban project boards to visualize workflows,
providing managers and team members with a simple overview of a project from start to
finish. Trello’s key components are boards, lists, and cards. [6]

1.5.4 Modelling language

After a lot of reflexion for choosing the method, we also chose UML as the unified modeling
language. Our selection was based on the strengths of this language and in particular on
its standardisation and the various programs it provides. UML also presents the best tool
to map complex systems in a simplified and standardized graphical and text format.

9
1.5.5 Project Steering

We need to specify the work team as well as the roles assigned to each of them, the time
blocks and the artifacts in order to pilot a project with Scrum.
There are many ways to pilot a Scrum project such as having a table that contains the
task to be done and the advancement of the sprints. A handful of tools exist that allow
us to track the tasks like easyBacklog, Jira, OrangeScrum or ScrumDo.

1.5.6 Scrum Roles

The team play a key role in Scrum and it consists of 3 roles:

• Product Owner: A Product Owner is in charge of making sure that a Scrum team
gets the requested final product done, they know very well what are the market
tendencies and the client expectations.

• Scrum Master: A Scrum Master is in charge of making sure that a Scrum team
works as efficiently as possible, they do daily Scrum meetings and sprint plannings,
provide suggestions that would help improve the project, give instructions and

• Development Team: A development team consists of professionals that do the prac-

tical work of accomplishing the tasks given by the Scrum Master, they also play a
part in lending help in sprint planning and objective setting. [4]

1.6 Back-log

1.6.1 Product Backlog

The task-level specifics required to carry out the roadmap’s strategy are listed and
prioritized in a product backlog. The backlog should outline the tasks the development
team has to complete in order to carry out the broad goals of the plan. A product backlog
frequently include tasks like user stories, bug fixes, and other activities. [1]
We will show in the table 1.2 our own Product Backlog that we came up with:

10
 Table 1.2: SBS Monitor Product Backlog

Story I want to be able Prior Compl

As A ... So that... Sprint
ID to... -ity -exity
I can check my
Create an ac-
1 Visitor monthly work Must 1 2
count
sheets
I can add my
2 Visitor Login daily work Must 1 2
sheets
See the list of all I can monitor
3 Administrator Must 1 1
users users
I Allow users
Add new
4 Administrator to work on a Must 1 1
projects
project
Pick a project I can add my
5 User Must 2 2
I’m working on task
My monthly
Add my tasks in
6 User sheets get up- Must 2 2
my daily sheets
dated
Check users Validate or Re-
7 Administrator Must 3 2
monthly sheets ject them
See the status
Check my own
8 User of my monthly Must 3 2
monthly sheets
sheets
Know more
Speak to a chat- informations
9 User Could 3 3
bot about the com-
pany

11
 Check my own
10 User profile informa- Edit my profile Could 3 2
tions
Check the list of Archive a
11 Administrator Could 3 3
projects project
Check the list of
12 Administrator Bill a Project Could 3 3
archive projects

1.6.2 Global Architecture

Before we get into the conception part, we need to specify the software architecture
in advance. In order to build our application, we opted for this architecture consisted
essentially of:

Figure 1.4: Global Architecture

12
 • Front-end : It is a mobile and web application developed with the Flutter framework
while making use of the Dart programming language and also implementing other
libraries. It communicates with the back-end by using the http package which
provides the simplest way to fetch data from the database.

• Back-end : It is a very important role for our project whether it comes to the web
part or the mobile part. This is the part that describes the functionalities offered
by our application. This section provides communication with our database and the
front-end part exposed to the user using the technologies Node.js and express.

• Database: This is the component where we store our application’s datas. In our
case, we chose to use a NoSql format that is MongoDB.

1.6.3 Conclusion

We have tried through this chapter to first of all present the host company, as well as
the work to be done and the methodology adopted. We then did a theoretical overview
of the overall architecture of our application by showing some of the appropriate tools for
the proper conduct of the work. In the end we opened the way to focus on the various
critiques of the existing on the market in the upcoming chapter while drawing up the
specifications and the needs for our application.

13
Chapter 2

Needs Analysis and Specification

2.1 Introduction
The needs analysis phase is the starting point for every project. In fact, the application
needs to be perfectly suitable to the client and his expectations in order for it to be
successful and ensure that it serves its purpose. In this chapter, we come up with a clear
vision of the various expected needs of our project as well as a detailed analysis of the
expected functionalities.

2.2 Identification of Actors

In this section we will identify the actors in our application and their respective roles
and exclusive features.
Actors:

• Manager: In our application, the manager is considered an administrator, he is one

of the main actors in our project. He has the right to manage projects in both the
mobile application and the web dashboard, as well as managing the bills and users
by monitoring their activities throughout the entire calendar year or month. he can
also archive the projects that the company finished working on and can bill them.

• Consultant: this actor plays the main role of the application even though he is
considered as a normal user whether he is a developer or a collaborator as long as
he’s part of the company. It is the one that benefits from the different services of

14
 the application. He needs to add his daily tasks and the projects he’s worked on
and can check his monthly sheets afterwards. He also has the possibility to speak
with a chat bot in order to learn more about the company.

2.3 Critique of Existing

The development of our project must be preceded by a preliminary study that identifies
the actual needs that will clarify the design and implementation later. In this part, we
will present our study based on the Software Dynamics Nav and state the importance
of integrating a brand new mobile application that gives us an internal solution to track
employees and manage projects in the business processes of companies as well as its
advantages.

Figure 2.1: Internal Software Dynamics Nav

15
 Based on what we previously announced and a comparison between the industry needs
and current activities, we have deduced that the current method seems unsuitable, slow,
unadvanced and is in need of an upgrade. Following a full study phase of the current
system, we found the following problems:

• Slow processing that could lead to many errors.

• The UI is not smooth and is rather complicated.

• Only one person can get online at a time, otherwise the other person gets automat-
ically disconnected.

• Lack of traceability of the different monitoring processes by the manager.

• Only accessible as a Desktop Application.

2.3.1 Comparative Study

Data Integrity Security Architecture

Existing Solution Unstable

New Application Stable

2.3.2 The Expected needs of the Application

Both the functional requirements that the system will execute and the non-functional
criteria that raise the system’s software quality must be satisfied by the anticipated re-
quirements of the imagined application.

2.3.3 Functional Requirements

The actions that the application is capable of performing are listed in the functional
requirements. They are specifications of the system’s input/output behavior.
The application automatically checks the existence of monthly sheets at the beginning of
each month and adds the monthly sheet if it doesn’t exist, then it gets updated every
time a user adds his daily sheet.
Any user who has installed the application will have the right to :

16
 • Register and sign in.

• Retrieve his password.

• Add his daily tasks and pick the project he’s working on.

• Take a day off.

• Check his daily sheets.

• Check his monthly sheets and their statistics, he can also sort them by year.

• Use the chat bot.

• Check and modify his profile.

• Check the list of other registered users.

The manager who will be the administrator of the application and the web dashboard
will be able to :

• Add a new project.

• Consult projects.

• Monitor users monthly sheets, daily sheets and their activities.

• Archive finished projects.

• Bill archived projects.

• Acquire the bill.

• Manage users monthly sheets such as validating it, rejecting it or looking at its
details.

2.3.4 Non-Functional Requirements

The operational requirements, which define the system’s performance as well as its
security and ergonomics, are referred to as non-functional requirements.

• Security : The application must guarantee the integrity and confidentiality of the
data to the connected user. Our system must also certify the availability.

17
 • Reliability and speed, scalability and reusability of resources.

• The ergonomics of the UI : The UI of a mobile application is delicate. It must be

simple and clear and the manipulation of the interface should not require advanced
knowledge.

• Robustness :The application must support the storage of user data and offer effective
error handling.

2.4 Diagrams

2.4.1 Global Use Case Diagram

A use case diagram is a type of UML diagram that shows the overall functional behavior
of a software system. It is helpful for presentations to management or project actors. Our
global use case diagram is shown in the figure 2.2 below:

Figure 2.2: Global Use Case Diagram

18
2.4.2 Class Diagram

Now we move on to the class diagram, it’s a structure that will show us our system’s
classes and their attributes, the operations and the relationship between our objects.

Figure 2.3: Class Diagram

2.5 Conclusion
During this chapter, we were able to identify the actors of our application and do a cri-
tique of the existing, while specifying the functional requirements and the non-functional
requirements.

19
Chapter 3

Solution Development

3.1 Sprint 1 : Preparing the web Services

3.1.1 Introduction

The first sprint is a period at the end of which the team delivers a potentially deliv-
erable product increment. In our case, the solution is a mobile Flutter application and a
web dashboard that allows the company to monitor its consultants.

3.1.2 Sprint Backlog

Every sprint has a goal, and I associate it to a list of tasks in the product backlog that
need to be completed. The first sprint’s backlog is listed in the table 3.1 below, with an
estimate in days, the difficulties range is between [A-D] with A being the most difficult
and the priorities range is between [1-4] with 1 being the most important task.

Table 3.1: Sprint 1 Backlog

Task Diffi- Prio- Esti-

User Story Task
ID culty rity mation
Stroyless 0.1 Initializing a Node Project C 1 0.1
0.2 Integrating "Express" and "Mongoose" C 1 0.2
0.3 Creating Index.js File D 1 0.1
0.4 Connecting to the Database B 1 0.3

20
 Creating the view which includes all the
0.5 routes, controllers and models files that D 1 1
we’ll be using in our project.
User Manage- Integrating "Jsonwebtoken" in our
1.1 D 1 0.1
ment Node project
1.2 Creating Middleware.js file D 1 0.1
1.3 Implementing the Sign Up Method B 1 1
Implementing the Login with a token
1.4 A 1 2
Method
1.5 Implementing CRUD methods B 2 0.5
Project Manage-
2.1 Implementing CRUD Methods B 1 0.3
ment
Implementing Sort user by date, month
2.2 B 1 0.5
and year Method
Implementing "Archive Project "
2.3 B 2 1
Method by the administrator
Daily Sheet
3.1 Implementing CRUD Methods B 1 0.3
Management
3.2 Implementing Sort by User Method B 1 1
3.3 Implementing Input control on the date B 1 1
Monthly Sheet Implementing "Confirm" and " Reject "
4.1 B 1 2
Management methods by the administrator
4.2 Implementing Sort by Year Method B 1 1
Implementing Input control on the
4.3 C 1 1
Date
Implementing "Automatic Add
4.4 A 1 3
Method" once a new month starts
4.5 Implementing "Increment Method" A 1 2
Bills Manage- Implementing "Bill Archived Projects"
5.1 B 2 4
ment method by the administrator

21
 Tests And De-
6.1 Installing Postman D 3 1
ployment
Testing all the routes methods on Post-
6.2 A 1 7
man
6.3 Fixing all the Errors after Testing A 1 7

3.1.3 Detailed Architecture

3.1.3.1 Detailed Backend Architecture

We started with the detailed architecture of the Back-end part. This architecture is
presented in the figure 3.1:

Figure 3.1: NodeJS Architecture

The most well-known feature of Node.js is its asynchronous, event-driven, non-blocking

I/O processing. The single-threaded event loop paradigm of Javascript provides the ma-
jority of the concurrency and asynchronism that it needs.

3.1.4 Used Technologies

We will state the used technologies below:

22
3.1.4.1 Node.js

Node.js (Node) is an open source development platform for executing JavaScript code
server-side. Node is useful for developing applications that require a persistent connection
from the browser to the server and is often used for real-time applications such as chat,
news feeds and web push notifications. [5]

Figure 3.2: NodeJs Logo

3.1.4.2 MongoDB

MongoDB is a document-oriented database. Simply put, you get the scalability and
flexibility you want, with the query and indexing features you need. [3]

Figure 3.3: MongoDB Logo

3.1.4.3 Visual Studio Code

Visual Studio Code is a source-code editor developed by Microsoft.

Figure 3.4: Visual Studio Code Logo

3.1.4.4 Postman

The main purpose of postman is writing tests. Tests confirm that your API is working as
expected, that integrations between services are functioning reliably, and that any changes
haven’t broken existing functionality. You can write test scripts for your Postman API
requests in JavaScript. You can also use test code to aid the debugging process when
something goes wrong with your API project. [9]

23
 Figure 3.5: Postman Logo

3.1.5 Test and Realization

After the end of the Sprint, we managed to develop the back-end part of our applica-
tion. In order to test our solution we used Postman to try out the requests. In the figure
3.6 we will show an example of a request that we tested:

Figure 3.6: Postman Request Test

This specific request allowed us to display all the daily sheets by a certain user in the
month of Jully 2022.

24
3.1.6 Conclusion

In this sprint, we have successfully designed, developed and deployed the web services
of our application. Now, let’s move on to Sprint 2, where we will develop our mobile
application.

3.2 Sprint 2 : Mobile Application Development

3.2.1 Introduction

To give our client a full product, we must now develop our mobile application after
finishing working on the web services. The choice of technologies for the mobile application
is where this chapter begins. Then we will elaborate on our sprint backlog before showing
some screenshots for this sprint’s realisation phase.

3.2.2 Sprint Backlog

The backlog for this sprint is displayed in the table 3.2. When developing our mobile
application, it is utilized to assess the tasks’ difficulty and get a broad picture of what
needs to be done, with an estimate in days.

Table 3.2: Sprint 2 Backlog

Task Esti-
User Story Task
ID mation
Stroyless 0.1 Initializing a Flutter Project 0.1
Installation and configuration of the required
0.2 1
packages
0.3 Creating Index.js File 0.1
0.4 Configuring "AndroidManifest.xml" file 0.5
0.5 Installing a good Android Emulator 0.5
Creating the view which includes all the
0.6 routes, controllers and models files that we’ll 1
be using in our project.

25
As a user, I would like
to use the mobile ap- 1.1 Creation of the Authentication interface 0.5
plication
Implementing the "login method" in "lo-
1.2.1 2
gin.dart" file
Calling the login method in the login button
and navigating to 2 different routes depend-
1.2.2 1
ing on the role for the "User" and the "Ad-
ministrator"
1.2.3 Enable user access in mongodb 1
1.3.1 Creation of the Registration Interface 2
Implementing the "Register Method" in
1.3.2 2
"Signup.dart" file
1.3.3 Call the "Register Method" 0.5
1.4.1 Creation of the "Forget Password Interface 1
1.4.2 Installing "mailer " package 0.5
Implementing the "Forgot Password Method"
1.4.3 2
in "ForgetPass.dart" file
1.5.1 Creating "Welcome Page " Interface 2
Creating "Logout Method " in the Wel-
1.5.2 2
comePage.dart
Creating the "Persistent Bottom Navigation
1.5.3 Bar" that allows the user to navigate through 2
multiple pages
Call the "Logout Method " in the logout But-
1.5.4 2
ton
As a user, I would
Creating the "Display Monthly Sheets" Inter-
like to manage my 2.1 1
face
monthly sheets
Implementing CRUD Methods in Display-
2.2 2
MonthlySheets.dart file

26
 Implementing the "Sort By Year " Method in
2.3 2
DisplayMonthlySheets.dart file
As a user, I would like
to manage my daily 3.1 Creating the "Add Daily Sheets" Interface 1
sheets
Creating a button in the Display Monthly
3.2 Sheets Interface that allows the navigation 1
to "Add Daily Sheet" UI
3.3 Creating "Add Daily Sheet " Interface 7
Creating a dropdown list for the available
3.3 projects to pick from in the "Add Daily Sheet 2
" Interface
Implementing CRUD Methods for the daily
3.5 2
sheet
Implementing "Check If Exist Method" for
3.6 3
the daily sheet
3.7 Creating "Take a Day Off" Interface 1
Implementing "Automatic Monthly Sheet
3.8 Add Method" in monthly sheets file after a 1
user adds his daily sheet.
Implementing "Increment Method" in
3.9 monthly sheets file after a user adds his 1
daily sheet.
As an administrator, I
would like to manage 4.1 Creating the "Add Project" Interface 1
projects
4.2 Creating the "Display Project" Interface 1
Creating the CRUD methods for project
4.3 2
management in Projects.dart file
As a user, I would like
to know more about 5.1 Creating the "Live Chat Bot " Interface 2
the company

27
 5.1 Installing the Chat Bot Package 2
5.2 Creating the "Live Chat Bot Methods" 2
5.3 Configuring the Chat Bot 2
As a user, I would like
to look at others pro- 6.1 Creating the "Users List Method" 2
files
6.2 Creating the "Users List " Interface 2
6.3 Creating the "User Own Info Method " 2
6.4 Creating the "User Info " Interface 2

3.2.3 Used Technologies

3.2.3.1 Choice of Technology

Table 3.3: Technology Comparison

Framework Advantages Disadvantages

• Rich in widgets

• Consistent UI

• Cross-Platform
• The packages are quickly
• Common bugs are fixed fre-
obsolete and to be updated
Flutter quently
• Still New
• Low Cost

• Time Saving, allows you to reuse

some of your code in other inter-
faces

28
 • Low Cost
• Supports moslty light APIs
• Time saving only
React Na-
• Allows you to share the code be- • In-depth knowledge re-
tive
tween the two iOS and Android quired
operating systems (OS)

• Many UI components available

• Unstable Native Plugins
and easy to work with.
Ionic • Random Crashes while
• Fast development and time to
building the application
market

After giving it a lot of thoughts, I, alongside my manager, have decided that we should
try a new technology that is Flutter and get started.

3.2.4 Technologies

3.2.4.1 Flutter

Google’s portable UI toolkit, Flutter, allows developers to create stunning, natively built
applications from a single codebase for desktop, mobile, and the web. Flutter is free and
open source, integrates with existing code, and is utilized by developers and businesses
all over the world. [7]

• Multiplatform: Mobile, web, desktop, and embedded device deployment from a

single codebase.

• Stable and Dependable: Flutter is used and sponsored by Google, endorsed by well-
known brands worldwide, and upheld by a community of international developers.

• Developer Experience: Automated testing, developer tools, and everything else you
need to create production-quality apps will help you take control of your codebase.

29
 Figure 3.7: Flutter Logo

3.2.4.2 Dart

Dart is a general-purpose, object-oriented, open-source programming language with C-

style syntax that Google created in 2011. [8]

Figure 3.8: Dart Logo

3.2.4.3 Android Studio

Android Studio is an IDE for Google Android Development launched on 16th May 2013,
during Google’s I/O 2013 event. It can also be used for flutter development. [2]

Figure 3.9: Android Studio Logo

3.2.5 Mobile Application Architecture

3.2.5.1 Design Pattern

Figure 3.10: Design Pattern

30
3.2.5.2 Detailed Frontend Architecture

Now we’re moving on to the detailed architecture of our Front-end part which are shown
in figure 3.11

Figure 3.11: Flutter Architecture

31
3.2.6 Conception

3.2.6.1 Use Case Diagram

Figure 3.12: Daily Sheet Use Case Diagram

3.2.6.2 Descriptive Table

Table 3.4: Descriptive Table for User Use Case Diagram

Use Case Daily Sheet Management
This use case allows the consultant to fill in his daily
Objective
sheet
Actor Consultant

32
 • an authentication is required
Precondition
• having active projects

• The list of daily sheets will be displayed on the

screen
Post-condition
• The monthly sheets will be updated

This use case will allow the consultant to:

• Insert a daily sheet by affecting it to a project and

a task
Description
• Display the list of daily sheets

• Edit a daily sheet

• Expired token which leads to close the session and

logout
Exceptions
• No daily sheet added yet by the consultant to be
either displayed or edited.

3.2.6.3 Sequence Diagram

UML interaction diagrams include sequence diagrams. They serve as a representation of

message exchanges between objects and are employed to illustrate various usage scenarios
for the system. We will model the sequence diagram for "Authenticate" based on the
textual descriptions of the use case diagram in the figure 3.13, the user will start inserting
his login details in order to get access to the mobile application, and if he doesn’t have an
account, he will get notified by a message response and can either navigate to the register
interface to make a new account or use the forget password function if he already has one
that he can’t remember.

33
Figure 3.13: Sign Up And Login Sequence Diagram

34
 Then we will move to the 2nd figure 3.14 where the user will insert his daily sheet, he
has to make sure there are currently available projects that the company work with and
the administrator has added to the database in order to pick one, then he has to make
sure that he hasn’t added a task in that specific date and finally the system will check if
the current monthly sheet exists or not, if it doesn’t the system will add it automatically,
then add the user’s daily sheet and finally update it the newly added monthly sheet. And
if the monthly sheet exists, it will be just updated and the user’s daily sheet will also be
added.

Figure 3.14: User Insert Sequence Diagram

35
3.2.7 Realisation

We will present the interfaces of our application, describing each time the UI compo-
sition that the user interacts with.
The first UI shown in the figure 3.15 shows the login interface where we can find the SBS
logo upfront, the user can have access to the application by getting a Token once he types
down his username and password correctly. he can also navigate to either the Sign UP
page in case he doesn’t have an account yet or the Forgotten Password page where he can
retrieve his password by typing down his E-mail address. The second screenshot in the
figure 3.16 is the first UI after logging in and the welcome page of our Application where
the user can also logout.

Figure 3.15: Login Interface Figure 3.16: Welcome Page Interface

36
 These two pages represent respectively the Sign UP page in the figure 3.17 and the
Forgot Password page in the figure3.18.

Figure 3.17: Sign UP Interface Figure 3.18: Forgot Password Interface

37
 This page in the figure 3.19 represents the user’s monthly sheets page where the user
can see the status of his monthly sheets and also his statistics throughout that month,
such as how many days he worked, how many holidays he got and how many times he
took a leave. He can also navigate to another two pages. The first one is the "Insert a
Daily Sheet" sheet page and the second is where he can take a leave. He has the ability
to sort his monthly sheets by the year as shown in the second figure 3.20.

Figure 3.19: Monthly Sheets Interface Figure 3.20: Sort Monthly Sheets

38
 The first figure 3.21 represents the "Add a Daily Sheet " page where the user can add
his task, pick the current project he’s working on as shown in the second figure 3.22 and
indicate for how long.

Figure 3.21: Insert A Daily Sheet UI Figure 3.22: Pick A Project

39
 This is still the same "Insert a Daily Sheet " UI, but here we are showing other features.
The first screenshot in the figure 3.23 shows us where the User can tell if he needed to
go to the client’s workplace during that day and the type of vehicle he used to do so. If
he used a Taxi, he can write down the price. On the other hand, the second screenshot
that is shown in the figure 3.24 is an error message that pops up if the user didn’t add a
valid date, or if the date that the user is trying to add already exists before and he can
not override it.

Figure 3.23: Type of Vehicle

Figure 3.24: Error Message 1

40
 If the user meets all the requirements, he will be able to add his daily sheet and
a message that will notify him will pop up then he’ll be directed back to the monthly
sheets UI as shown in the figure 3.25, an internal function in the application triggers after
the user adds a daily sheet, the application checks if the monthly sheet of the current
month and year doesn’t exist in the database and adds it, then it starts incrementing by
1 depending on the type of day as shown in the figure3.26.

Figure 3.25: Success Message Figure 3.26: Monthly Sheet Added

41
 In the figure 3.27, we can see the page that represents the list of Daily Sheets. The
user can have access to this page simply by clicking on the container from the Monthly
Sheet Page in the previous interface in the figure3.19. Then in the second figure 3.28, he
can see the details of the selected daily sheet.

Figure 3.27: List of Daily Sheets Figure 3.28: Daily Sheet

42
 In the figure 3.29, we can see how the user can take a day off, it is also accessible from
the monthly sheets interface in the figure 3.19. the figure 3.30 shows how the user can
pick a date.

Figure 3.29: Day Off Figure 3.30: Picking a Date

43
 The first figure 3.31 shows us the calendar UI, where the user’s tasks are displayed
according to their respective dates whereas in the second figure3.32, we can see a chat
bot integrated in the application that helps the user answer the most important questions
about the company or the use of the application.

Figure 3.31: Calendar Figure 3.32: Chat Bot

44
 The first page as shown in the figure 3.33 allows the user to look at registered users
and the second page in the figure 3.34is where the user can check his personal information.

Figure 3.33: Users Information Figure 3.34: Users Profile

45
 This space is exclusive for the administrator. In the figure 3.35, the administrator can
add new projects to allow users to work on and in the figure 3.36 he can look at existing
projects.

Figure 3.35: Add Projects Figure 3.36: Display Projects

3.2.8 Conclusion

This was the second sprint where we successfully started consuming our web services in
our Mobile application using http packages. We started off with a small introduction and
showed the sprint backlog, followed by the technologies as well as the architecture used
for the frontend then finished it off with screenshots showing how the application works.
In the next sprint, we’ll be looking at the web dashboard that only the administrator has
access to.

46
3.3 Sprint 3 : Web Dashboard Development

3.3.1 Introduction

After mostly finishing the consultant part of our application, we must now develop our
web dashboard where the administrator will monitor the users and can see which project
they’re working on, which tasks they accomplished during that time while validating or
rejecting their monthly sheets. We chose the same technologies as the mobile application
which is the Flutter Framework since it is cross-platform and very suitable to this kind
of application. Therefore, this time, we will start by elaborating on our sprint backlog,
we will study the conception part and then we will see the realization of our third sprint
accompanied by a couple of screenshots from the dashboard.

3.3.2 Sprint Backlog

Table 3.5: Sprint 3 Backlog Table

Task Esti-
User Story Task
ID mation
Initializing a Flutter Project (A different
Stroyless 0.1 project from the mobile app one, but with 0.1
the same classes)
0.2 Installing the required libraries 1
Creating the views, routes, controllers and
0.3 1
models
As an administrator, I
would like to use the 1.1 Creation of the Authentication UI 1
web dashboard
1.2 Implementing the login method 1
Creating "Dashboard Welcome Page " Inter-
1.3 2
face
Creating overall statistics for the users,
1.4 1
projects, bills and sheets.

47
 Creating the "Side Menu" Interface that al-
1.5 lows the administrator to navigatre through 3
his pages
As an administrator, I
would like to check my 2.1 Creating the "Display Users" Interface 1
consultants
2.2 Implement "Last Updated " Method 2
2.3 Display Users Informations 2
As an administrator, I
would like to manage
3.1 Creating the "Display Users" Interface 1
my consultants and
their sheets
3.2 Create the " User Monthly Sheet" interface 3
Create a button that allows the administra-
3.3 tor to navigate to the " User Monthly Sheet 2
UI"
Display the detail of a specific user’s monthly
3.4 4
sheets
3.5.1 Creating the " Validate " Button 0.2
Implementing the "Validate Daily Sheet
3.5.2 1
Method " and call it in the "Validate " Button
3.6.1 Creating the " Reject " Button 0.2
Implementing the "Reject Daily Sheet
3.6.2 0.5
Method " and call it in the "Reject " Button
3.7.1 Creating the "User’s Daily Sheets interface" 2
3.7.2 Creating the " Details " Button 0.2
Implementing "Check User’s Monthly Sheets
3.7.3 Detail " Method and call it in the "Details " 3
Button
3.7.4 Check a user’s daily sheets 1

48
As an administrator, I
Creating the "Display Current Projects" In-
would like to manage 4.1 1
terface
my projects
4.2 Displaying the current projects information 2
4.3.1 Creating the "Add Project " interface 1
4.3.2 Creating the "Add button" 0.2
Implementing the "Add method" and calling
4.3.3 2
it in the "Add Button"
4.4.1 Creating the "Archive" Button 2
Implementing the "Archive Project Method"
4.4.2 7
and calling it in the "Archive Button"
4.4.3 Creating the "Archived Projects " Interface 2
Creating the "Navigate Method" that allows
the user to navigate directly to an updated
4.4.4 version of the "Archived Projects" interface 7
and call it in the "Archive " Button as well,
it triggers after the "Archive Project Method"
As an administrator, I
would like to manage 5.1 Creating the "Display Bills" Interface 2
my bills
5.2 Creating the "Insert Bill Interface" 1
Creating the "Bill" button inside the
5.3.1 0.5
"Archived Projects" interface
Creating the "Bill" method and call in the
bill button, it allows the administrator to go
5.3.2 3
to the Bill Interface while preserving the se-
lected project’s datas
Implementing the "Bill A Project Method"
5.3.3 and call it in the "Finalize Bill" Button inside 4
the "Insert A Bill Interface"

49
 5.4.1 Creating a "Bill Detail " interface 2
5.4.2 Creating the " Details " Button 0.5
Implementing the "Check Details Method"
5.4.3 that allows the administrator to navigate to 2
a specific bill’s details page
Implementing the "Convert to PDF and
5.4.4 3
download Method" using the PDF API

3.3.3 Conception

Now we will move to the conception phase where we will show the use case diagrams and
sequence diagrams that we used in our project.

3.3.3.1 Monitoring Users Use Case Diagram

Figure 3.37: Monitoring Users Use Case Diagram

50
3.3.3.2 Monitoring Users Descriptive Table

Table 3.6: Monitoring User Descriptive Table

Use Case Users Management
This use case allows the manager to monitor his consul-
Objective
tants and manage their monthly and daily sheets
Actor Manager

• an authentication is required

• having registered users in the application

Precondition
• having active users who already filled their sheets.

• Users monthly sheets will be updated

Post-condition • Users will be see an updated monthly sheet status

on their mobile application

This use case will allow the manager to:

• See the list of users

• See a specific user’s monthly sheets and their sta-

tus

Description • See the details of the user’s monthly sheets which

will be in the form of daily sheets list

• Validate a user’s monthly sheet

• Reject a user’s monthly sheet

• No user was found

Exceptions
• No daily sheet added yet by the consultant.

51
3.3.3.3 Project Management Use Case Diagram

Figure 3.38: Project Management Use Case Diagram

3.3.3.4 Project Management Descriptive Table

Table 3.7: Project Management Descriptive Table

Use Case Projects Management

Objective This use case allows the user to manage projects
Actor Manager

• an authentication is required
Precondition
• having current projects to archive

52
 • New projects will be added
Post-condition
• Current Projects will be archived

This use case will allow the manager to:

• Add a project

• Delete a project

• See the list of all the projects

Description
• Archive a project

• See the detail of each project

• Edit a project

• No current project was found to be archived.

Exceptions

3.3.3.5 Bills Management Use Case Diagram

Figure 3.39: Bills Management Use Case Diagram

53
3.3.3.6 Bills Management Descriptive Table

Table 3.8: Bills Management Descriptive Table

Use Case Bills Management

Objective This use case allows the user to bill archived projects
Actor Manager

• an authentication is required
Precondition
• having archived projects to bill

• New bills will be added

Post-condition

This use case will allow the manager to:

• Add a bill affected to the archived project

Description • Display Bills

• Turn the bill into pdf format

• No archived project was found to be billed.

Exceptions

After showing the various use case diagrams and their respective descriptive table, we will
now proceed and show the different sequence diagrams that are also used in this sprint.

3.3.3.7 Monitoring Sequence Diagram

The figure 3.40 shows us the monitoring system sequence diagram that our application
"SBS Monitor" will implement, the administrator will have access to the admin panel
where he will exercise his rights to whether validate or reject the users monthly sheets, he
will start by navigating to the Users Interface if there are registered users in the mobile
application, he will then pick a specific user and check his monthly sheets details, for each
monthly sheets there are three buttons which are "accept", "reject" or "details", if he clicks

54
on details he will see the daily sheets of that month then the get data method will be
executed and a success response will be returned. If he presses Accept, the accept method
will be executed and the user’s monthly sheet will be updated and if he pressed on reject,
the user’s monthly sheet will also be updated.

Figure 3.40: Monitoring Sequence Diagram

55
3.3.3.8 Projects and Bills Management Sequence Diagram

The figure 3.41 shows us the Projects and Bills management sequence diagram, first
the administrator will open the dashboard, head to the list of projects and adds a new
project, it will trigger the add method and then the new project will be added and a
success message will be returned. The manager then would like to archive the project
that the company finished working on, so in case there are actual projects, he will head
to the projects list where he can find the archive button and archive the said project, a
success message will appear and he will be redirected to the archived projects list where
he can bill it. After he pressed the bill button, the Bill method will be executed and the
bill will be added to the database, another notification will also appear. At the end, the
administrator can choose to extract a pdf version of this bill.

Figure 3.41: Projects and Bills Management Sequence Diagram

56
3.3.4 Realisation

Now we move on to the realisation part, where we will be showing our administrator web
dashboard that we built using Flutter.

3.3.4.1 Web Dashboard Home Page

We will start by showing the home page in the figure 3.42, where we can see the logo of
the SBS company, the dashboard header and a fixed Side Menu under it where the ad-
ministrator can navigate through different pages. We can also see the number of projects,
users, bills, and sheets that are saved in our database. In the first page, there is also the
list of users.

Figure 3.42: Dashboard Home Page

3.3.4.2 Users List

In the figure 3.43, we can clearly see a more detailed version of the list of users that are
registered in the database through the mobile application, as well as their usernames,

57
the last time they updated their daily sheets and their roles. There is a monthly sheets
details button that allows the administrator to navigate to the next page and see more
information about the specific user’s sheets. And lastly, there is the fixed Side Menu and
the header that never disappear in each page.

Figure 3.43: Dashboard List of Users

3.3.4.3 The Monthly Sheets of a specific user

In the figure 3.44, we can see the list of monthly sheets of a certain user after pressing
the details button from the previous page. This is where the manager can monitor his
employees and check their daily sheets. It contains the month, year, number of days
worked, number of days off as well as days where he took a leave, the status of that sheet
and three buttons "Confirm", "Reject", and "Details" . First he will check the details of
the monthly sheet he wants to see in the next interface and then he goes back to this one
to either validate or refuse the sheet depending on the performance of the user.

58
 Figure 3.44: The Monthly Sheets of a user

3.3.4.4 The Daily Sheets of a specific user

In the figure 3.45, we can see the details of a monthly sheet that the administrator selected
in the previous page, which is the monthly sheets page in the form of daily sheets. He
can monitor the user and check his workload each day, as well as the task done, the client
he’s working for and the name of the project. There is also the price of transportation if
the user had to travel to meet with the client and finish his job.

Figure 3.45: The Daily Sheets of a user

59
3.3.4.5 Projects List

In the figure 3.46, the list of current projects is displayed for the administrator, as well
as an "Add" button that allows him to Add a new project to the list. The administrator
can also archive a project that the company finished working on.

Figure 3.46: Projects List

3.3.4.6 Add Project Interface

The figure 3.47 is the interface where the administrator has access to after pressing the
"Add " Button in the previous figure 3.46. All he has to do is fill this form and press the
add button and he will have a new project in the database.

Figure 3.47: Add a Project in Dashboard

60
3.3.4.7 Archived Projects

The figure 3.48 shows us the list of the archived projects in the database, the user can
navigate to it using the side menu or he will be redirected to it automatically after
archiving a project as shown in the figure 3.46. He can then proceed and Bill a project.

Figure 3.48: Archived Projects

3.3.4.8 Bill A Project

In the figure 3.49, the user will fill this form in order to complete his billing after selecting
a project in the figure 3.48

Figure 3.49: Bill A Project

61
3.3.4.9 Bills List

The figure 3.50 shows us the list of bills that the administrator has added in the database.
The detail button allows him to navigate to the bill page where he can see its details.

Figure 3.50: Bills List

3.3.4.10 Bill Detail

This figure 3.51 shows us the detail of the selected bill.

Figure 3.51: Bill Interface

62
3.3.5 Conclusion

This the third and last sprint presented the last part of our end of studies project where
we successfully built our web dashboard and also consumed our web services. There-
fore, finishing the entire application and carrying out various tests to ensure that it is
functioning in the right way.

63
Chapter 4

Sprint

PLACEHOLDER

64
General Conclusion

IT technological advancements have made it possible to create brand-new services that

offer significant value enhancements over some old services.

During this project, we have tried to solve some problems that the SBS company might
have had to face, with modern solutions brought to us and the help of the new rising
technology “Flutter” that is still getting better after every update.

In order to achieve this work in an optimized and effective way, we have studied this
technology and focused on its qualities to see whether it matches the company’s needs.

We made a full study on the problem, tried to find various solutions, set a plan based on
our knowledge and experience and followed it to accomplish this project after facing some
obstacles that helped us improve and deepen our skill.

In the end, we finally got our end product which is a modern and simple to use mobile
application followed with an administrator panel that the company was satisfied with.

Thanks to this application, this company will now be able to successfully get a grip on
their employees’ work more frequently and find more suitable companies to work with.

Nevertheless, our application is likely to have new evolutions and upcoming updates.

65
Summary

The current project was developed at the SBS company to obtain the engineering degree in
software and computer engineering. The principal goal of this project is to create a mobile
application that makes the management of the company’s consultants and projects easier,
and also a web dashboard for the manager to monitor them using the Flutter technology
for the front-end, Node Js for the back-end and MongoDB as our database. This project
was carried out using an agile methodology (SCRUM).

Keywords : Flutter, NodeJS, MongoDB, UML, Postman, Visual Studio

66
References

[1] Product Backlog. What is a Product Backlog? | Definition and Overview. url: https:
//www.productplan.com/glossary/product-backlog/.

[2] Prithviraj Biswas. Introduction to Android Studio | LoginRadius Blog. url: https://
www.loginradius.com/blog/engineering/introduction-to-android-studio/.

[3] com. What Is MongoDB? url: https://www.mongodb.com/en/what-is-mongodb.

[4] Coursera. The 3 Scrum Roles and Responsibilities, Explained. July 2022. url: https:
//www.coursera.org/articles/scrum-roles-and-responsibilities.

[5] James Denman. What is Node.js? Apr. 2012. url: https://www.techtarget.com/

whatis/definition/Nodejs.

[6] Matthew Finnegan. What is Trello? Apr. 2018. url: https://www.computerworld.

com/article/3226447/what-is-trello-a-guide-to-atlassians-collaboration-
and-work-management-tool.html.

[7] FAQ Flutter. Flutter Definition. 2022. url: https://docs.flutter.dev/resources/

faq.

[8] Java Point. What is Dart Programming. url: https : / / www . javatpoint . com /
flutter-dart-programming.

[9] Learning Postman. Writing tests. July 2022. url: https : / / learning . postman .
com/docs/writing-scripts/test-scripts/.

67