Tunisian Republic Higher Institute of Applied

Ministry of Higher Education Sciences and Technology

And Scientific Research de Sousse
University of Sousse

INFORMATICS DEPARTMENT

GRADUATION INTERNSHIP PROJECT REPORT

Elaborated to obtain a National Engineering diploma in:

Software Engineering
Specialty : Software Architecture

Development and Deployment of Bumbal

Academy LMS
Elaborated by:

Azer Taboubi

Presented on 19 / 10 / 2022 to the jury:

President: Sami Achour ISSAT Sousse

Examiner: Dalel Kanzari ISSAT Sousse

Supervisor: Farouk Cherif ISSAT Sousse

Industrial Mortada Abdul Roda Bumbal B.V.

supervisor:

Academic Year: 2021/2022 Subject Code: FI‐GL22‐022

Abstract

This report has been prepared as part of the final project for the diploma in computer engineering. The
objective of this assignment was to design, develop and deploy a learning management system for the
company's transport management solution that will enable the company to grow rapidly and improve its
performance in engaging new customers.

Keywords: learning management system, guides, courses, progress, deployment, support…

i
Dedication

It is with great pleasure that I dedicate this work.

To my dear mother Hasna.

You gave me life, tenderness, and courage to succeed, all I can offer you will not be able to express the
love and gratitude I have for you.
To express the love and gratitude I have for you. I offer you this work to thank you for
I offer you this work to thank you for your sacrifices and for the affection you have always shown me.

To my dear father Bechir

No tribute can be equal to the love and esteem I have for you. You
You have always advised, guided, and supported me in difficult times. I hope to be able to
I hope that today I can fulfil one of your dreams and always live up to your expectations.

To my dear sister Ghofran

No homage can be equal to the love and esteem I have for you. You have always offered me advice and
support in difficult times. I hope I can make one of your wishes come true today and always meet your
expectations.

To my aunts and uncles

I would like to thank them for their great love, affection, and tenderness.

To my friends
I cannot find the right and sincere words to express my affection and thoughts to you.
thoughts, you are for me brothers and sisters on whom I can count.

To my teachers
Thank you for sharing your passion for teaching. I have greatly appreciated your support, involvement,
and experience throughout my years of study.

ii
Acknowledgement

At the end of this internship, I would like to express my deepest gratitude to everyone who has helped in
any way to achieve this work, and in particular:

My supervisor, the CEO of Bumbal Mr. Mortada Abdul Roda, for looking after me and offering me the
best conditions to finish my work.

My academic advisor Mr. Farouk Cherif, for the advice and assistance he provided me in carrying out this
work.

The jury members, for evaluating my work and enlightening me with their knowledge.

The ISSAT So Family, all my dear teachers, friends, and colleagues.

iii
Contents

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

1. General Project Presentation ................................................................................................................. 3

1.1. Host Organization ......................................................................................................................... 3

1.1.1. Presentation ........................................................................................................................... 3

1.1.2. Main Activities...................................................................................................................... 4

1.2. General project description ........................................................................................................... 5

1.2.1. Project Scope ........................................................................................................................ 5

1.2.2. Problem and Motivation........................................................................................................ 5

1.2.3. Proposed Solution ................................................................................................................. 5

1.2.4. Targets................................................................................................................................... 6

1.3. Existing Solutions ......................................................................................................................... 6

1.3.1. Talent LMS ........................................................................................................................... 6

1.3.2. Coassemble ........................................................................................................................... 7

1.3.3. Teamie................................................................................................................................... 8

1.3.4. Limitations ............................................................................................................................ 8

1.4. Work methodology ....................................................................................................................... 9

1.4.1. Agile methods ....................................................................................................................... 9

1.4.2. Comparison between classic and agile methods ................................................................... 9

1.4.3. Scrum method ..................................................................................................................... 11

1.4.3.1. Scrum Roles ................................................................................................................ 11

1.4.3.2. Scrum Events .............................................................................................................. 12

1.4.3.3. Scrum Artifacts ........................................................................................................... 13

1.4.3.4. Product Backlog .......................................................................................................... 14

iv
 1.4.4. Software modelling methodology ....................................................................................... 17

Conclusion .......................................................................................................................................... 18

2. Requirements specification ................................................................................................................. 19

2.1. Actors .......................................................................................................................................... 19

2.2. Project requirements ................................................................................................................... 20

2.2.1. Functional requirements...................................................................................................... 20

2.2.2. Non-functional requirements .............................................................................................. 21

2.3. Use case diagram ........................................................................................................................ 21

2.3.1. General diagram .................................................................................................................. 21

2.3.2. Detailed use case diagram of the “Authentication & User Account Management” features
23

2.3.2.1. Refinement of the use case "Login": ........................................................................... 24

2.3.2.2. Refinement of the use case "Register": ....................................................................... 24

2.3.2.3. Refinement of the use case "Check profile": .............................................................. 25

2.3.2.4. Refinement of the use case "sign out":........................................................................ 25

2.3.2.5. Refinement of the use case "reset password": ............................................................. 26

2.3.3. Detailed use case diagram of the “Course Management & Course Enrollment” features .. 27

2.3.3.1. Refinement of the use case "Enroll in Course": .......................................................... 28

2.3.3.2. Refinement of the use case "Consult Enrollment": ..................................................... 28

2.3.3.3. Refinement of the use case "Enroll in Course": .......................................................... 29

2.3.3.4. Refinement of the use case "Check Course": .............................................................. 29

Conclusion .......................................................................................................................................... 30

3. System Design .................................................................................................................................... 31

3.1. Static view of the application ...................................................................................................... 31

3.2. Dynamic view of the application ................................................................................................ 33

3.2.1. Use case “Register” sequence diagram ............................................................................... 33

3.2.2. Use case “Check progress” sequence diagram.................................................................... 34

v
 3.2.3. Use Case “Add Course” sequence diagram ........................................................................ 34

3.2.4. Activity diagram ................................................................................................................. 35

Conclusion .......................................................................................................................................... 37

4. Realization .......................................................................................................................................... 38

4.1. Technological environment......................................................................................................... 38

4.2. Implementation Tools ................................................................................................................. 40

4.3. Physical Architecture .................................................................................................................. 40

4.4. Testing, Automation and CI/CD ................................................................................................. 41

4.4.1. Testing................................................................................................................................. 42

4.4.1.1. UI Testing ................................................................................................................... 42

4.4.1.2. Unit Testing................................................................................................................. 42

4.4.2. Automation and CI/CD ....................................................................................................... 43

4.4.2.1. Continuous Integration ................................................................................................ 44

4.4.2.2. Continuous Delivery and Deployment ........................................................................ 46

4.4.2.3. CI/CD Pipeline ............................................................................................................ 48

4.5. Implementation ........................................................................................................................... 48

4.5.1. Interfaces of the application ................................................................................................ 49

4.5.2. Experienced problems ......................................................................................................... 55

Conclusion .......................................................................................................................................... 56

General conclusion and perspectives .......................................................................................................... 57

vi
Table of Figures

Figure 1: Scrum Development Process ....................................................................................................... 11

Figure 2 UML Diagrams ............................................................................................................................. 17
Figure 3 General Use Case Diagram........................................................................................................... 22
Figure 4 Use case diagram of “Authentication & User Account Management” features ........................... 23
Figure 5 Use Case Diagram of "course management & course enrollment" .............................................. 27
Figure 6: Static Architecture ....................................................................................................................... 31
Figure 7: Class Diagram ............................................................................................................................. 32
Figure 8 Use Case "Register" Sequence Diagram ...................................................................................... 33
Figure 9 Use case “Check progress” sequence diagram ............................................................................. 34
Figure 10 Use Case “Add Course” sequence diagram ................................................................................ 35
Figure 11 Activity Diagram ........................................................................................................................ 36
Figure 12 Application Architecture ........................................................................................................... 41
Figure 13 CI/CD pipeline............................................................................................................................ 44
Figure 14: Continuous Integration Workflow Diagram .............................................................................. 46
Figure 15: Continuous Delivery Workflow Diagram ................................................................................. 47
Figure 16 CI/CD Workflow Diagram ......................................................................................................... 48
Figure 17: Sprints Planification .................................................................................................................. 49
Figure 18: Login form ................................................................................................................................. 49
Figure 19: Email Verification Code Reception........................................................................................... 50
Figure 20: First Section of Home Page ....................................................................................................... 50
Figure 21: Second Section of Home Page .................................................................................................. 51
Figure 22: Third Section of Home Page ..................................................................................................... 52
Figure 23: Admin Course............................................................................................................................ 52
Figure 24: Admin Course Chapters ............................................................................................................ 53
Figure 25: Subchapters of Activiteiten ....................................................................................................... 53
Figure 26: User Guide ................................................................................................................................. 54
Figure 27: Users Management .................................................................................................................... 55

vii
List of Tables

Table 1: Existing solutions limitations.......................................................................................................... 8

Table 2: Classic and Agile methods comparison ........................................................................................ 10
Table 3: Product Backlog........................................................................................................................... 17

viii
Abbreviations

API: Application Programming Interface ..................................................................................................... 3

DB: Data Base............................................................................................................................................. 40
ERP: Enterprise Resource Planning.............................................................................................................. 3
ETA: Estimated Timing of Arrival ............................................................................................................... 4
HTTP: Hyper Text Transfer Protocol ......................................................................................................... 40
IDE: Integrated Development Environment ............................................................................................... 40
LMS: Learning Management System ........................................................................................................... 9
SaaS: Software as a Service .......................................................................................................................... 3
SME: Small Midsized Enterprises ................................................................................................................ 3
TMS: Transport Management System .......................................................................................................... 3
UML: Unified Modeling Language ............................................................................................................ 38

ix
General Introduction

Everything you have tomorrow depends on how much learning you do now. Learning is a lifetime process.

With the advancement of IT tools, their widespread use in enterprises of all sizes, and their emergence, it
is now possible to obtain a sizable return on investment, which is primarily demonstrated by the decrease
in costs and the increase in productivity.

Learning today takes many different forms, but the most popular one is what is known as "E-Learning,"
which is a learning system based on electronic materials that takes place online.

The company wants to stay in touch with its customers, involve them in the process of product
improvement, and provide them a wonderful experience.

Businesses looking for effective and simple-to-integrate solutions to let their customers learn about the
product they are using are becoming more and more common.

In this light, our goal is to develop a web site specifically for course management.

Considering the solution's effectiveness and competitiveness. Technologies like shared services and SOA
are effective ways to increase flexibility to meet business needs.

The many phases of our effort are described in this report. It is divided into five chapters as follows:

• The first chapter is devoted to presenting the project's overall framework, methodology, and
formalism used.

• The second chapter details the actors in our application, the use case diagrams, and the functional
and non-functional requirements.

• By explaining both the static view and the dynamic view, the third chapter describes the design of
our software in greater depth.

• The fourth chapter describes the deployment procedure, implementation, and technologies. The
physical architecture and interfaces of our application are also covered in this chapter.

1
We finish by offering a broad conclusion that will summarize the work done and suggest some potential
next directions.

2
1. General Project Presentation

In this chapter, we will first introduce the host organization and its primary functions before looking at the
existing solutions to break down the issue and gain a deeper knowledge of what needs to be done.

1.1. Host Organization

The work presented in this report was made as a part of the Web development Chapter within Bumbal. This
section will allow us to have a global overview about the host organization and its sectors of activity.

1.1.1. Presentation

Bumbal is a company that has developed its own TMS, called Bumbal. The company focuses on
implementing, developing, and publishing the software. Bumbal is used by SME, companies where the core
business is not logistics. Bumbal's TMS works according to the SaaS principle and is offered completely
online.

In total there are now 135 companies actively using Bumbal's software locally and globally. These
companies are in the following target groups: construction, printing, electronics, bicycles, hospitality,
couriers, garden/furniture, and health care.

Customers can plan various things such as appointments, trips, deliveries. In addition, the customer can use
the track & trace and communicate with end customers. It is not possible to do invoicing via Bumbal, for
example. Bumbal has been developed in such a way that it can be used not only with any ERP, TMS, or
webshop system, but also with other systems thanks to the API, which Bumbal uses.

3
On the one hand, the Bumbal application is used to determine position for the automatic ETA updates for
both customer and planner. On the other, the application is for the instruction of drivers and the registration
of execution. Among other things, the following items are to be found in the application:

• Route schedules available for driver with sequence of stops, and within stops loading or service
rules (what is to be delivered / collected or service visit).
• Loading lists per ride (survey of products that must be carried in that ride).
• Registration times of arrival and departure.
• Digital signature.
• Option to take pictures.
• Registration packaging.
• Scanning barcodes (also bulk scanning several barcodes at the same time).
• Processing driver instructions (both separate instructions going with the order concerned or stem
instructions with addresses).
• Registration remarks drivers.
• Adding extra (non-planned) driver activities.
• Registration of irregularities (shortage of delivery / damage), if so desired, incl. photo – signature.

What is registered by the driver on the road, is also immediately available in the activities and ride dossier
of the planner or other employees (think of sales or customer service). If so desired, you can also
automatically send on by e-mail the registered shortages of delivery or irregularities to, for instance,
customer service staff so that immediate action can be taken.

1.1.2. Main Activities

Bumbal provides easy software for perfect customer appointments and a grip on transport, so no vehicle
will drive around unnecessarily.

• Making appointments with customers for service or delivery.

• Determine the estimated time of arrival.
• Tracking and tracing the status of all rides that are underway available.

4
 1.2. General project description

We will describe the project's context in this section, as well as the problem description, its limits, and
potential remedies.

1.2.1. Project Scope

Using our application, we can learn about Bumbal at our own pace, manuals and instructional videos for
the application actors will become available. If something is not completely clear, we can check it all in
this online environment. this way we gain insight into all the functionalities of the transport software, and
we can make optimal use of Bumbal.

1.2.2. Problem and Motivation

Admission might be challenging for new clients because it takes a lot of time to thoroughly record oneself
and learn about Bumbal TMS. As a result, there is an increasing demand for support staff to answer calls
during business hours and provide fixes for frequent issues. On occasion, various employees of the same
client organization would make the identical requirement.

Tutorials can offer a great method to engage current consumers or attract new ones, depending on the quality
of the content shared on the platform.

1.2.3. Proposed Solution

We will create a solution that addresses all the mentioned issues. A web application called Bumbal Learning
Management System will make it easier for the customer to get involved, give him the option of selecting
his learning path and learning the various features he can use, give him the opportunity to assess himself
and track his progress, and help him become more precise and successful during his learning period.

Additionally, it will make it possible for the mentor to keep an eye on the training and ensure that the
immersion process is effective. Moreover, it enables the admin to create every required piece of
documentation to operate our platform, such as courses, manuals, techniques, and exercises.

5
 1.2.4. Targets

Our goal is to create a platform that satisfies the need to convince current and potential customers of the
value and use of Bumbal TMS capabilities.

In fact, there are two primary components to our solution:

The learner can select the course and the lesson based on his needs and monitor its progress in a customer
section.

An administrative component that gives the application's administrator access to the capabilities offered to
the learner or customer allows them to manage the content.

Our application must also adhere to standards for high-quality software, including usability, clarity, speed,
compatibility, security, and efficiency.

1.3. Existing Solutions

In this section, we analyze the existing solutions that can meet our client's needs to identify the strengths
and limitations of these solutions.

1.3.1. Talent LMS

It is an all-in-one learning management system that offers flexible course creation features, gamification
and certification, and various other learning tools.

But its most valuable offering is an extensive course marketplace. A well-curated library,

where learners can buy courses. There are over 400 courses to choose from. Pick an individual

6
course, or buy a course bundle with access to multiple courses. If you decide you want to add more to it,
TalentLMS allows you to edit and supplement the course to your liking. You can add your own video,
audio, images, and other content, reorder the lessons, or add tests and assignments.

1.3.2. Coassemble

It helps you build a visually appealing course, with presentations and other interactive content to keep
employees engaged.

The app is equipped with numerous content templates to help you get started.

For example, the presentation templates allow you to create flowcharts, springy lists, drop-tabs, word
circles, and slide-in text. This granular level of customization extends to the assessments.

There are many full-fledged quiz templates to choose from for every lesson, and the question types include
options like spot the mistake, choose the correct image, hotspot, or label a diagram, in addition to more
standard question types. To enhance your course further, you can

add case studies, slideshows, and images with text overlay.

7
 1.3.3. Teamie

It is more like a group learning when you will create classrooms, chat together and share knowledge, you
can also access some courses and see your task list and create assessments that will be available anytime.
Contains a forum where students can post questions and interact with each other.

1.3.4. Limitations

Solution Advantages Limitations

TalentLMS • Ability to create courses in different • Can’t track learners
format: video, sound, and text. • No feedback system
• Ability to add test and assessments • Can’t create projects and
• Wide set of varied courses assignments
• Gamification
Coassemble • Interactive courses • No feedback system
• Varied course presentation templates • Can’t track learners progress
• Can include quiz inside a course and skills
• Ability to mentor learners • Can’t create projects and
assignments
Teamie • Social platform • No managing system
• Chat and co-learning
• Tasks and To-do list
• Progress tracking
• Feedback

Table 1: Existing solutions limitations

8
Most of the LMS platforms contains varied database of lessons, some assessment systems and sometimes
a forum or a small co-learning and knowledge sharing area, but nearly all of the either lack or don’t have a
consistent mentoring and managing system, where mentors can provide feedback, supervise learners and
track their progress to see which area they need to improve in order to fit with organization goals, moreover
there is no system that is dedicated to a certain organization that shows company situation within a
dashboard that could be helpful to describe its current state and to decide next steps.

The solution we propose must overcome these limitations by providing the appropriate inspection
functionality to our customer.

1.4. Work methodology

In our project, we will work in a team predefined by the company in the goal of building a product that
satisfies the requirements and visions of the project. Since this field is ever evolving and new ideas may
come up later during development, it adds complexity to the project which can’t be predicted and outlined
from the start, so, working in the Scrum [1] Agile [2] method is a justifiable choice because it will
provide a more flexible approach to adapt to the changing environment and needs.

1.4.1. Agile methods

Agile methods are a way to reduce the development cycle of IT projects, to respond more quickly to changes
in end-user demands. Agile IT projects are managed in an adaptive, incremental, and iterative way. Even
today, in the field of software development projects, agile methods are increasingly used. As their names
indicate, they are dynamic and reactive project management methods.

1.4.2. Comparison between classic and agile methods

The following table will explain the differences between the classic and agile methods. It will also justify
our choice of using an agile method.

9
Project Element Classic Method Agile Method
Life Cycle Sequential phases, making Iterative and incremental
returns at the level of the development allowing for
configuration very difficult. adjustments during sprints.
Planification Predictive and relatively Adaptive throughout the project
detailed. Defined from the by depending on the evolutions
beginning of the project based on with several planning levels.
a stable scope and requirements.
Documentation Produced in large quantities. Reduced to the bare minimum
according to the increments.
Quality Quality control at the end of the Quality control from the start of
development cycle. The the project and permanent.
customer discovers the finished Future users visualize the results
product at the end of the project. of the configuration
continuously.
Change Suddenly arrives at the end of the Change can be made between
phase of Implementation. each increment.
Access Compliance with initial Customer satisfaction. Speed of
commitments based on the implementation
cost/deadline/quality.

Table 2: Classic and Agile methods comparison

10
 1.4.3. Scrum method

Scrum is considered an agile work methodology that relies on cutting a project in time boxes called
“sprints”. A sprint is typically a couple of weeks long. Each sprint starts with an estimation followed by an
operational planification. At the end of the sprint, the goal is to ship an improved version of a working
product.

Figure 1: Scrum Development Process

1.4.3.1. Scrum Roles

• Mortada Abdul Roda: product owner, is the product owner, he represents the customer’s best
interests and acts more like a business consultant/advisor/coach etc. for the client.

• Sebastian Smid: scrum master, is the scrum master, he oversees managing the scrum process,
supervising tasks realization, and discussing new features with the product owner.

• Kimverhoven, Rick Van loon and I, scrum development team: will be the development team with
the mission of implementing the wireframes Frontend, Backend and DevOps solutions.

11
 1.4.3.2. Scrum Events

Below is a list of all the key ceremonies a scrum team might partake in:

• Sprint: All the events, from planning to retrospective, happen during the sprint. Once a certain time
interval for a sprint is established, it must remain consistent throughout the development period.
This helps the team learn from past experiences and apply that insight to future sprints.

• Sprint planning: The work to be performed (scope) during the current sprint is planned during this
meeting by the entire development team. This meeting is led by the scrum master and is where the
team decides on the sprint goal. Specific use stories are then added to the sprint from the product
backlog. These stories always align with the goal and are also agreed upon by the scrum team to be
feasible to implement during the sprint. At the end of the planning meeting, every scrum member
needs to be clear on what can be delivered in the sprint and how the increment can be delivered.

• Daily scrum or stand up: This is a daily super-short meeting that happens at the same time (usually
mornings) and a place to keep it simple. Many teams try to complete the meeting in 15 minutes,
but that’s just a guideline. This meeting is also called a ‘daily stand-up’ emphasizing that it needs
to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page,
aligned with the sprint goal, and to get a plan out for the next 24 hours.

• Sprint review: During this event, the Scrum Team and stakeholders review what was accomplished
in the Sprint and what has changed in their environment. Based on this information, attendees
collaborate on what to do next. The Product Backlog may also be adjusted to meet new
opportunities. The Sprint Review is a working session, and the Scrum Team should avoid limiting
it to a presentation.

• Sprint retrospective: The purpose of the Sprint Retrospective is to plan ways to increase quality and
effectiveness. The Scrum Team identifies the most helpful changes to improve its effectiveness.
The most impactful improvements are addressed as soon as possible. They may even be added to
the Sprint Backlog for the next Sprint.

12
 The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a
one-month Sprint. For shorter Sprints, the event is usually shorter.

1.4.3.3. Scrum Artifacts

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information.
Thus, everyone inspecting them has the same basis for adaptation.

• Product Backlog: The product backlog is a prioritized list of initial customers’ requirements for the
product to be produced. This document constantly evolves during the project, according to the
needs of the client. The product owner is responsible for the product backlog.

• Sprint Backlog: The Sprint Backlog is composed of the Sprint Goal (why), the set of Product
Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the
Increment (how). The Sprint Backlog is a plan by and for the Developers. It is a highly visible,
real-time picture of the work that the Developers plan to accomplish during the Sprint to achieve
the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is
learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

• Increment: An Increment is a concrete steppingstone toward the Product Goal. Each Increment is
additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
To provide value, the Increment must be usable. Multiple Increments may be created within a
Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism.
However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint
Review should never be considered a gate to releasing value.

13
 1.4.3.4. Product Backlog

Feature Feature ID User User Story Priority Estimation

ID Story

1.1 As an Anonymous user I want High 4 days

to be able to Register.

1 Authentication
And High 2 days
1.2
As an Anonymous user I want
User to be able to Login.
Management
High 8 days
1.3 As an Anonymous user I want
to be able to reset my
password using my email.

1.4 Normal 2 days

As an Admin, I want to be
able to see the list of learners.

1.5 Normal 2 days

As an Admin, I want to be
able to add a new learner.

1.6 Normal 2 days

As an Admin, I want to be
able to delete a learner.

1.7 Low 2 days

As a Learner, I want to be
able to logout.

14
 1.8 Low 3 days
As a Learner, I can reset my
password if I forget it.

1.9 Normal 3 days

As a Learner, I want to be
able to manage my profile.

2.1 High 4 days

Course As an Admin, I want to be
Management able to create a course.

2
2.2 Low 2 days
As an Admin, I want to be
able to delete a course.

2.2 High 2 days

As a Learner, I want to be
able to see the list of the
courses.

2.3 Medium 2 days

As Learner, I want to be able
to enroll in courses.

2.4 Medium 3 days

As a Learner, I want to be able
to consult my enrollments.

2.5 Low 4 days

As a Learner, I want to be
able to check each course.

15
 3.1 High 3 days
Learning As a Learner, I want to be able
Process to check my partial progress.
3

3.2 As a Learner, I want to be able High 4 days

to check my global progress.

Solution 4.1 Abstract project configuration High 5 days

4 in global environment
architecture
variables.

and durably

4.2 Create the docker image for High 1 day

the backend.

4.3 Build the frontend and High 1 day

backend distributions

4.4 Create the deployment scripts. High 2 days

4.5 Automatically deploy project High 2 days

parts on each new release.

4.6 Setup development work High 1 day

environment.

16
 4.7 Setup production work High 1 day
environment.

4.8 Build a CI/CD[2] pipeline that High 5 days

will trigger with VCS[3]
actions.

Table 3: Product Backlog

1.4.4. Software modelling methodology

After choosing the software development methodology, we need a unified modelling language for
modelling the software to be developed. To design our system, we chose UML as our modelling language.
Our choice was based on the strengths of this language, notably its standardization and the various diagrams
it poses. Also, UML is the best tool for schematizing complex real systems in a simplified and standardized
graphical and textual format with the help of a standardized language. The development process is based
on diagrams with different semantics.

The figure below shows the different UML [4] diagrams and their roles.

Figure 2 UML Diagrams

17
Conclusion

In this first chapter, we first presented the framework of the project and the host organization. Subsequently,
we have given a description of the subject, our problems, and the solution we adopted. Finally, we described
the working methodology.

In the next chapter, we analyze the client's needs by outlining the main functionalities of our software.

18
2. Requirements specification

In this chapter we present an analysis of the customer's needs. We start by identifying the actors who will
interact with our application. Then we describe the functional and non-functional requirements of the
customer. Then we detail the required functionality of our future software through use case diagrams.

2.1. Actors

To make our platform easy to use and manage, we divided our actors into three types of users:

• Anonymous: The anonymous user is a non-authenticated user, which can visit the application
content and have a global overview of it, but he can’t benefit from the application services.

• Admin: has the highest privileges in our application, his role is to manage the content of the
platform like adding resources, track progress, define target skills, and create learning programs
besides managing programs.

• Learners: we can say that learners are the most important players in our product and can be
represented as the fuel of our platform. They will be invited to register for a program and within it
they must acquire skills, taking courses and passing assignments, to successfully complete a
milestone or step in the program.

Our actors are structured in a pyramid scheme where each role obtains all the advantages of the roles that
preceded it.

19
 2.2. Project requirements

In this section, we will define the different functional requirements and the non-functional requirements
that we will achieve during the implementation of our solution.

2.2.1. Functional requirements

The system must allow the Anonymous user to:

• Have a global overview of some manuals.

The system must allow the learner to:

• Login into the platform

• Logout of the application
• Pick one of the courses
• Have an overview of the subjects of each course
• Monitor the partial progress
• Monitor the global progress
• Navigate easily from tab to another using navbar
• Track the enrollments
• Send feedback.

The system must allow the administrator to:

• Manage learner’s progress

• Supervise learners within the program
• Create content on the platform
• Have the same privileges as the learner

20
 2.2.2. Non-functional requirements

Having determined the functional requirements, we present below the set of constraints to be respected to
guarantee the performance of the application. To produce a high-performance product that respects the
user's requirements and that can cope with risks of failure or malfunction, the application developed must
consider the following elements:

• Usability: The application should offer a clear overview of the different functionalities of the
application.
• Ergonomic: The content is clear, and the operations are easy to make for a non-technical person
• Security: The application must be secured using secure frameworks and cloud resources.
• Availability: the application should contain a dev and prod environment and an easy integration
between them, so that it will be always available and easy to migrate to new releases without
maintenance period.
• Scalability: Setup a scalable architecture that can oversee changes and unexpected obstacles.
• Portability: The system must work properly and be compatible with any browser for the web part
and any version of the operating system for the mobile part.

2.3. Use case diagram

2.3.1. General diagram

The user interface will provide us with a global overview of the relation between our users and the different
functionalities.

21
 Figure 3 General Use Case Diagram

To be able to interact with any feature of the application, the user must be authenticated first. After that, he
can perform certain actions depending on his role.

22
 2.3.2. Detailed use case diagram of the “Authentication & User Account
Management” features

The diagram below shows the use cases that we tackled when working on Authentication and User
account management:

Figure 4 Use case diagram of “Authentication & User Account Management” features

23
 2.3.2.1. Refinement of the use case "Login":

• Use case: sign in

• Actor: anonymous
• Precondition:

– The anonymous downloads the application.

– The anonymous goes through the splash screen and clicks on the "Login" button.

– The anonymous opens the Login in form.

• Post condition:

– The anonymous create an account.

– The anonymous becomes a learner.

• Main scenario:
– The anonymous fills the Login in form with his username, email, and password.
– The anonymous gets a validation email.
– The anonymous activates its account and login to the platform.
• Exception:
– The system will show alert message if the email or the username already exists.
– The system will show alert message if the password doesn’t follow the required strength
characteristics.

2.3.2.2. Refinement of the use case "Register":

• Use case: sign up

• Actor: Anonymous
• Precondition:

– The anonymous opens the application.

– The anonymous clicks on the " Register" button in the bottom of the Login in form.

– The anonymous opens the Register form.

• Post condition:

– The anonymous signs up to his account.

24
 – The anonymous becomes a learner.

• Main scenario:

– The anonymous fills the Register form with his username and password.

– The anonymous logins to the platform.

• Exception:

– The system will show alert message if the password or the username are wrong.

2.3.2.3. Refinement of the use case "Check profile":

• Use case: Check profile

• Actor: Learner
• Precondition:

– The Learner signed in successfully.

• Post condition:

– The profile screen is displayed.

• Main scenario:

– The learner clicks on his avatar image in the right upper corner of the home screen.

– The learner is redirected to his profile screen.

• Exception:

– The learner is redirected to home screen.

2.3.2.4. Refinement of the use case "sign out":

• Use case: sign out

• Actor: Learner
• Precondition:

– The learner is showing his profile screen.

25
 – The Learner becomes an Anonymous.

• Post condition:

– The learner is in the login screen.

– The learner becomes an Anonymous.

• Main scenario:

– The learner clicks on the "sign out" button in the profile screen.

– The learner is redirected to the login screen.

2.3.2.5. Refinement of the use case "reset password":

• Use case: reset password

• Actor: anonymous
• Precondition:
– The anonymous opens the application.
– The goes through the splash screen and clicks on the "Login" button.
– The anonymous clicks on the "Register" button in the bottom of the sign in form.
– The anonymous opens the Register form.
– The anonymous forgot his password.
• Post condition:
– The anonymous reset his password.
– The anonymous Logs into his account.
– The anonymous becomes a learner.
• Main scenario:
– The anonymous clicks on "forgot your password?".
– The anonymous inserts his username or email in the text field.
– The anonymous receives a code in an email.
– The anonymous types of the confirmation code in the provided text field.
– The anonymous types of his new password and retypes it again.
– The anonymous gets redirected to the login form.
– The anonymous login to the platform.

26
• Exception:
– The system will show alert message if the username does not exist.
– The system will show alert message if the code is invalid.
– The system will inactivate the submission button if the two passwords don’t match.
– The system will show alert message if the password doesn’t follow the required strength
characteristics.

2.3.3. Detailed use case diagram of the “Course Management & Course
Enrollment” features

Figure 5 Use Case Diagram of "course management & course enrollment"

27
 2.3.3.1. Refinement of the use case "Enroll in Course":

• Use case: Create Course

• Actor: admin
• Precondition:

– The admin signed in successfully.

• Post condition:

– Course should be created.

• Main scenario:
–The admin selects courses.
–The admin selects add a new course.
–The admin fills in form of course’s basic information.
–The admin passes to next step which is creating the chapters included in the course.
–The admin validates the creation of the program.
• Exception:

– The Course already exists.

2.3.3.2. Refinement of the use case "Consult Enrollment":

• Use case: consult enrollment

• Actor: learner
• Precondition:

– The learner signed in successfully.

• Post condition:

– The learner can consult all the programs he’s enrolled in.

• Main scenario:
– The learner opens the home screen.
– The learner can scroll through the recently opened and the programs in progress.
• Exception:
– The system will show alert message if API can’t retrieve the data.

28
 2.3.3.3. Refinement of the use case "Enroll in Course":

• Use case: access course

• Actor: learner
• Precondition:

– The learner signed in successfully.

– The learner shows course details screen.

• Post condition:

– The learner gets redirected to the course link.

• Main scenario:

– The learner opens the course details screen.

– The learner clicks on start course button.

• Exception:

– The system will show alert message if link can’t be opened.

2.3.3.4. Refinement of the use case "Check Course":

• Use case: consult courses details

• Actor: learner
• Precondition:

– The learner signed in successfully.

– The learner shows course details screen.

• Post condition:

– The learner can consult all the course’s assignments.

– The learner can read the description of the course.

– The learner can consult the state of the course’s assignments.

• Main scenario:

– The learner opens the program details screen.

29
 – The learner clicks on the cell of the course he wants to consult its details.

• Exception:
– The system will show alert message if API can’t retrieve the data.

Conclusion

The specification and analysis of requirements provides a clearer view of the topic being addressed and a
deeper understanding of the tasks to be carried out and a more in-depth understanding of the tasks to be
carried out. In this chapter, we have defined some key terms related to our application domain.

In this chapter, we have defined some key terms related to the domain of our application.

Next, we identified the different actors in our system. We have carried out a study of the functional and
non-functional requirements. We have also modelled the functionalities of our application in use case
diagrams and provided their detailed description.

In the next chapter, we describe the static internal composition view of our application and the dynamic
behavior of its components.

30
3. System Design

The design phase, a crucial stage of critical importance in the project development cycle, is the subject of
this chapter. We begin by outlining the comprehensive and specific architecture of our program. Then we
go on to describe the dynamic behavior of our software, the communication between its various components
to perform the primary functionalities offered to the client, and the software.

3.1. Static view of the application

We applied the microservices architecture in our application. Indeed, an application is created as a

collection of small services according to the microservices architecture. Each service runs using a unique
process that interacts using simple mechanisms. The services were created around business logic that an
automated process may implement on its own. Despite being separate and autonomous, these services
interact with one another to deliver the required functionality.

This architecture has several benefits, including technological diversity, resistance to failure, adaptability,
simplicity in use, and reusability.

Figure 6: Static Architecture

31
Figure 7: Class Diagram

32
 3.2. Dynamic view of the application

3.2.1. Use case “Register” sequence diagram

The following figure shows the sequence diagram that displays all the action between the different system
layers when the Anonymous user is interacting with it so he can register himself on the application.

He starts with filling the registration form if the data is validated by frontend input checkers the requests
take its way to Laravel breeze authentication API, else the Anonymous user will be alerted. The register
form is dispatched, the email confirmation is sent thanks to the mailing service. Anonymous user enters the
confirmation code by clicking on the link found attached to the email and he will finally be redirected to
login screen.

Figure 8 Use Case "Register" Sequence Diagram

33
 3.2.2. Use case “Check progress” sequence diagram

The following figure shows the sequence diagram that displays all the action between the different system
layers when the learner user is interacting with it to display his own learning progress.

First the request tries to fetch the current logged in learner’s data, we make sure to only fetch the progress
from the database, so we avoid unnecessary transactions and interactions with the database.

Then we display the response we have got after parsing the query’s result.

Figure 9 Use case “Check progress” sequence diagram

3.2.3. Use Case “Add Course” sequence diagram

We will illustrate down below the sequence diagram of the use case in question, and we are going to try to
display the different interaction between the user and the system different components when working on
this issue:

34
 Figure 10 Use Case “Add Course” sequence diagram

3.2.4. Activity diagram

For more explanation about the behavior of the platform in this use case we have created an activity diagram
that will describe the different activities and steps that the user is going to pass through in order to
accomplish his requirements:

35
Figure 11 Activity Diagram

36
Conclusion

The internal components of our application's static view and its dynamic behavior are both covered in this
chapter. UML diagrams are used to demonstrate our description. We will outline our application's physical
architecture and a few interfaces in the following chapter.

37
4. Realization

In this chapter, we begin by describing the technologies and development environment with which this
project development environment with which this project was carried out. We will then present the physical
architecture and the main interfaces of our application.

4.1. Technological environment

In this part, we are interested in the programming languages, libraries and technologies used throughout the
realization of our application, justifying our choice. For the development of the proposed solution, we opted
for the use of frameworks. In fact, the framework has the following advantages:

• Not reinventing the wheel: thanks to ready-to-use business bricks (routing system, dependency
injection, asset management, cache system).
• Use good development practices: to design websites of professional quality websites.
• To remain free in the development of the functionalities and the future evolution of the realized
platform.
• To improve the productivity of the developers who use it.

In the following, we will present the technologies used.

• PHP: This acronym is a recursive acronym for PHP Hypertext Preprocessor. It is a general-
purpose, open-source scripting language, specially designed for the development of web
applications. It can be easily integrated with HTML.
• Lumen is an open-source PHP micro-framework created as an alternative to Laravel to meet the
demand of lightweight installations that are faster than existing PHP micro-frameworks such as
Slim and Silex.
• Typescript: is a free and open-source programming language developed and maintained by
Microsoft. It is a strict syntactical superset of JavaScript and adds optional static typing to the
language. It is designed for the development of large applications and transpires to JavaScript.
• React: is a free and open-source front-end JavaScript library for building user interfaces based on
UI components. It is maintained by Meta and a community of individual developers and companies.

38
• Material UI [6]: is simply a library that allows us to import and use different components to create
a user interface in our React applications. This saves a significant amount of time since the
developers do not need to write everything from scratch.
• Redux [7]: is an open-source JavaScript library for managing and centralizing application state. It
is most used with libraries such as React or Angular for building user interfaces. Like Facebook's
Flux architecture.
• MariaDB [8]: The MariaDB database is used for various purposes such as data warehousing, e-
commerce, enterprise-level features, and logging applications. It will efficiently enable you to meet
all your workload; it works in any cloud database and works at any scale small or large.
• Draw.io [9]: is proprietary software for making diagrams and charts. The software lets you choose
from an automatic layout function or create a custom layout.
• PHP Storm [10]: provides tools and code assistance features for working with databases and SQL
in your projects. Connect to databases, edit schemas, and table data, run queries, and even analyze
schemas with UML diagrams.
• Apache [11]: The Apache HTTP server is a software that runs in the background under an
appropriate operating system, which supports multi-tasking, and provides services to other
applications that connect to it, such as client web browsers.
• VSCode [12]: is a streamlined code editor with support for development operations like debugging,
task running, and version control. It aims to provide just the tools a developer needs for a quick
code-build-debug cycle and leaves more complex workflows to fuller featured IDEs, such as Visual
Studio IDE.
• Beanstalk [13]: is a Git-based code hosting tool.
• Git: is free and open-source software for distributed version control: tracking changes in any set of
files, usually used for coordinating work among programmers collaboratively developing source
code during software development.
• Insomnia API [14]: Insomnia is a free cross-platform desktop application that takes the pain out
of interacting with and designing HTTP-based APIs. Insomnia combines an easy-to-use interface
with advanced functionality like authentication helpers, code generation, and environment
variables.
• Node [15]: an open source, event-driven JavaScript software platform, which was created by Ryan
Dahl, with libraries to perform actions such as writing to standard output, opening/closing network
connections or creating a file.

39
 • Clickup [16]: is a cloud-based collaboration and project management tool suitable for businesses
of all sizes and industries. Features include communication and collaboration tools, task
assignments and statuses, alerts, and a task toolbar.
• Figma [17]: a collaborative web application for interface design, with additional offline features
enabled by desktop applications for macOS and Windows.
• Eloquent ORM [18]: is an object relational mapper that is included by default within the Laravel
framework. An ORM is software that facilitates handling database records by representing data as
objects, working as a layer of abstraction on top of the database engine used to store an application's
data.

4.2. Implementation Tools

To carry out the realization of our software we used as material environment a workstation having the
following characteristics.

• PC: Asus x556uj.

• CPU: Intel(R) Core (TM) i7-6500U CPU @ 2.50GHz 2.59 GHz.
• RAM: 8GB

4.3. Physical Architecture

In this part, we will describe the physical and software architecture used during the development of our
application.

Our solution is a web application that follows a n-tier architecture as shown in the picture below:

40
 Figure 12 Application Architecture

According to this architecture, our software is composed of:

• Presentation logic layer: it contains a front-end application server. This is the server that contains
the front-end application this one used by the end-users and that communicates directly with the
back-end application resident in the back-end server.
• Business logic layer: this contains the backend application server. This is the server that contains
the back-end application that accesses the data at the request of the front-end application to return
a content understandable and representable by the front-end application.
• Business data layer: It contains database servers that interact with the backend application servers.
These servers are used for the data persistence part of our application. It also contains three search
and indexing servers.

4.4. Testing, Automation and CI/CD

To ensure continuous integration, deployment, and monitoring of our app as well as the reliability of
our code and the adherence of every contribution made to the repository to the coding standards and
conventions used during the development of the solution, we had to add an automation level to our app.

41
 We will examine the architecture used to set up the pipeline and the jobs that will be triggered at each
contribution, as well as highlight the various services that will interfere with our system.

4.4.1. Testing

4.4.1.1. UI Testing

UI testing is a great way to ensure that your most basic UI collaborations continue to fill up as you add new
functionality or refactor your app’s codebase.

Composing and running UI tests isn’t quite the same as doing unit tests because you are collaborating with
your application, as opposed to performing tests on an API. It’s a good way to automate repetitive tasks,
especially when we’re working on UI logic.

Unit tests cannot verify the behavior of your application under real conditions. This is when you wanted to
use UI testing.

Functional testing using the user interface is generally the quickest and best approach to extending the
degree and depth of your testing to incorporate real-world conditions that coordinate each part of your
application.

UI testing can be another name for framework, practice, or recognition testing, where you test the entire
system together to ensure it does what it needs to do in real world scenarios.

UI testing will ensure that our application UI behaves correctly when expected actions are performed.

4.4.1.2. Unit Testing

Unit tests allows us to test very small units of a program. That is why there are so many of them. A unit test
will test a single method of a single class at most. If the method is large, it may even take several tests to
cover it.

A unit test makes it possible to check the correct functioning of a portion of a program: class, structure, or
a method.

This makes it possible to avoid a functional regression of the code when making updates, upgrades or
simply during a refactoring.

Finally, and this is not the least of their usefulness, unit tests are also used to find and fix bugs.

42
As hard as it sounds, it’s the truth: unit testing ultimately keeps track of the application’s logic, so the
developer doesn’t have to remember it himself.

At first it may seem easy to remember how and why the code behaves the way it does, but over time its
logic will inevitably expand, new developers may enter the arena, or the developer may just forget how
certain modules do or how they are supposed to work.

This is where unit testing saves your day. With a proper test suite, developers will be up to date with any
regressions added with newly introduced code before it gets pushed.

In addition, the developers in the team will feel much more comfortable knowing that no unit tests fail
during the first commits.

4.4.2. Automation and CI/CD

CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app
development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and
continuous deployment.

Specifically, CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of
applications, from integration and testing phases to delivery and deployment. Taken together, these
connected practices are often referred to as a "CI/CD pipeline" and are supported by development and
operations teams working together in an agile way with either a DevOps or site reliability engineering
(SRE) approach.

43
 Figure 13 CI/CD pipeline

4.4.2.1. Continuous Integration

Continuous integration is a method of DevOps software development in which developers regularly

integrate their code changes into a centralized repository, after which build, and test operations are carried
out automatically.

Continuous integration often refers to the creation or integration stage of the software release process and
involves an automated aspect and a cultural aspect.

The main goals of continuous integration are to find and fix bugs faster, improve software quality, and
reduce the time it takes to validate and release new software updates. In the past, developers within a single
team tended to work separately for long periods of time and only check in their changes into the centralized
repository after they finished working. This made the code change merge difficult and time consuming and
resulted in bugs for a long time without fixing.

The combination of these different factors made it difficult to deliver updates to customers quickly. With
continuous integration, developers regularly apply their changes to a shared repository, with a version
control system like Git. Before submitting their code, developers can choose to run tests on local units to
verify it further before integration.

44
A Continuous Integration Service automatically creates and runs unit tests on new code changes to
immediately detect any errors.

• Design and vision

As our repository branches are composed of two types a work or development branch that can be a new
feature, bugfix, build or chore and there is the main branch which is the principal branch where all the code
gets merge. Continuous integration was used in our project in every branch either it’s a feature development
branch or master branch.

The responsibility of our CI is to verify that the code is well written and follow the code conventions and
rules that we have agreed on, that the build phase is running smoothly and that all the test cases are passing.

The benefit of this work is to verify that at each contribution made to the repository the code is kept clean,
robust, and uniform and doesn’t break any previous feature.

• Implementation

To assure that in every new contribution a pipeline will be triggered to verify the needed requirements, we
have used the .beanstalk/workflows/ repository that contains the workflow files that will be interpreted by
beanstalk and used to run the described jobs.

We have used the Sonarqube code analyzer to verify our code quality, condition and matching to the rules
we have set, first we installed the Sonarqube as a development dependency to our project and then we are
creating Sonarqube.yml file which is the Sonarqube configuration or customization file, where we specified
the coding conventions we want to follow. We also created a Contribution.md markdown file that contains
all the conventions and ways of contributing to this repository.

To prepare the runtime environment of our CI pipeline beanstalk-hosted runners creates a docker image
that will contain all the needed packages and libraries that will be needed to run, build, and test the project.

45
 Figure 14: Continuous Integration Workflow Diagram

4.4.2.2. Continuous Delivery and Deployment

Continuous delivery is the logical continuation of continuous integration. In continuous integration, we try
to ensure that the code compiles well, but also that it is functional in production and of quality, by launching
unit tests as regularly as possible. But there are other types of testing, just as important, to ensure code
quality.

However, these tests cannot be run without having an environment deployed. Continuous delivery should
not be confused with continuous deployment, which is the logical continuation of continuous delivery.
These two disciplines aim to deploy an application in production. The difference is in the automation of
deployment to production. Continuous delivery stops before production and putting into production remains
a manual act (whether with a tool, or automated with the click of a button, or manually). The putting into
production is then subject to validation by a human being.

Continuous deployment, on the other hand, is the extension of continuous delivery:

46
deployment is done in an automated way through a pipeline. All compilation steps, unit tests and other
automated tests must then be green before proceeding with the deployment.

• Design and vision

We aim to create two environment for our application delivery and deployment processes, one is for staging
that will contains each new feature that have been merged into the main branch, meaning that every merge
is accepted to the main will be followed by a deployment job for the staging or development environment,
and a production environment that will be updated manually when the project manager decides to create a
release with the features that have been added lately.

• Implementation

This time we have updated our .beanstalk/workflows/ repository files and added the deployment scripts,
we added 2 new stages which are the development and production, in each one of them we checkout to the
target environment configuration and variables to assure independent deployment for each one, and then
we use some make commands to run the deployment scripts.

Jenkins is used here to make sure that the project can be deployed on multiple platforms. It also runs a
deep security scan on the CI/CD pipeline.

We used our private servers at the Iron Mountain Data center in Amsterdam to host our application.

Figure 15: Continuous Delivery Workflow Diagram

47
 4.4.2.3. CI/CD Pipeline

Based on the two cycles we presented above; we will now illustrate the full CI/CD pipeline diagram:

Figure 16 CI/CD Workflow Diagram

We had automated some processes to make our project maintainable and robust for further contribution.
We had started by defining both UI and unit testing, so we presented the continuous integration, delivery
and deployment definition, vision, and the way of implementation we followed in our application.

4.5. Implementation

To apply the methodology adopted for our project, we first defined a sprint task planning table. This table
enabled us to carry out the project the project and to ensure a good organization of the tasks.

The figure shows the sprint task planning table created by the online management tool Clickup that we
management tool Clickup that we used during our project.

48
 Figure 17: Sprints Planification

4.5.1. Interfaces of the application

Figure 18: Login form

49
If the user already has an account, he can fill the form with his username and password to finish his
authentication otherwise the user clicks on the "register" blue text at the bottom of the sign in form to be
redirected to the register form presented in the figure below after filling the form the user receives an email
with verification code to verify his email address. The figure presents the login form.

Figure 19: Email Verification Code Reception

The figure above presents a verification code email example that the user can receive either to activate his
account or reset his password.

Figure 20: First Section of Home Page

50
The figure above shows the home page for the application, where the learner can consult his achieved rate
global learning progress.

Figure 21: Second Section of Home Page

The Second section of the home screen provides the user with the opportunity to choose one of the available
learning courses on the platform.

51
 Figure 22: Third Section of Home Page

Figure 23: Admin Course

By clicking on the “Admin” course icon, the application redirects us to the main course’s page. We can see
the learner’s global rate progress and a screen shot of the Admin UI on the TMS.

52
 Figure 24: Admin Course Chapters

At the lower section of the Admin UI course, we can find the chapters included with the partial progress
rate bar on top of each chapter card.

Figure 25: Subchapters of Activiteiten

53
By clicking on one of the Admin’s course chapters we get redirected to “Activiteiten” chapter, we can see
the video attached to the subchapter, its description below, the partial progress rate at the top of the leften
menu represented by a moving truck, and the next button which can take us to read the next subchapter
after we are done with the current one.

Figure 26: User Guide

The “user manual” screen shown above is viewable by the ananymous users. We can find a written guide
illustrating the use of multiple feature of Bumbal’s TMS.

54
 Figure 27: Users Management

The above figure shows the user management interface which is restricted for Admins access only.

4.5.2. Experienced problems

During the development of our application, we encountered the following problems:

• It was challenging to alter material UI library components to fit our needs because the proposed
user interface differed significantly from the available components in terms of shape and size.
• The UI designer should consider relying heavily on the material UI library components for
inspiration.

• Lumen’s framework documentation is too brief, in a way it serves the purpose only for microservice
development.

• Using Redux for state management and centralization is not the best option for a web developer,
trying to fulfill complicated data exchange requests using it can take a lot of time to develop.
A better recommended option by redux team is to use Redux Toolkit instead.

55
 • Eloquent ORM is an extended method based on Query builder. It was developed to make a simple
source code, make and us faster to write our code. But since you must set your model’s name as
the table name, it's much less expressive.

Conclusion

The software and hardware environment, the automation and CI/CD process, as well as the many
technologies needed to build our application, have all been covered in this chapter. We started by describing
the physical architecture of our program, followed by a few interfaces. We've covered the interfaces and
physical architecture of our program, and we've completed by going over some issues that came up during
development.

56
General conclusion and perspectives

Our project is to create and deploy a web Learning Management System to make the immersion of clients
and easier.

Our project has as added values compared to the existing applications, the ability to track the learners
progress and manage the content.

We did a detailed study of the existing solutions. We also discussed the agile SCRUM methodology applied
for good management of our project. We exposed the planning of our work that allowed us to detail the
different tasks of our solution by specifying the user stories of the project and the order of priority of each
one. Then, we presented the product backlog of our solution as well as the functional and non-functional
requirements. We also discussed the analysis of these requirements. We tackled the design of the solution
in details. Finally last but not least, we implemented the user stories one by one, and we worked on adding
UI and unit tests and implementing them in a CI/CD pipeline.

Thanks to our experience at Bumbal, we learned from a personal point of view how to manage our project
in a methodical and organized way. This work has been beneficial to us since it allowed us to put into
practice our theoretical knowledge acquired throughout our training at the The Higher Institute of Applied
Sciences and Technologies of Sousse, and to learn new skills and technologies like Lumen, CI/CD pipeline
and Redux.

It also allowed us to deepen our knowledge and appreciate the importance of a project management
methodology. Our project is therefore a source of technical, cultural, personal, and human enrichment. The
environment of trust and respect with the superiors was favorable to achieve better productivity. Each stage
of our project required an effort and thorough research.

As perspectives, we suggest adding an internal chat system to the application. The product owner was very
pleased with our suggestion and asked us to do more research on this topic to start developing it as soon as
possible.

57
Bibliography

[1] What Are Agile Scrum Artifacts? | ClickUp: 01/08/2022.

[2] Node.js (nodejs.org) : 08/10/2022.

[3] Home - VCS Software – Intelligent Workforce Management: 06/07/2022.

[4] UML Tutorial (tutorialspoint.com): 05/07/2022

[4] Bumbal planning software | planning route | TMS: 02/08/2022.

[6] Beanstalk — Hassle-free Subversion and Git Hosting (beanstalkapp.com): 22/08/2022.

[7] Installation - Lumen - PHP Micro-Framework By Laravel: 10/06/2022.

[8] MUI: The React component library you always wanted: 11/06/2022.

[9] React – A JavaScript library for building user interfaces (reactjs.org): 12/07/2022.

[10] Redux - A predictable state container for JavaScript apps. | Redux: 20/07/2022.

[11] TypeScript: JavaScript With Syntax For Types. (typescriptlang.org): 30/08/2022.

[12] MariaDB Foundation - MariaDB.org: 15/06/2022.

[13] PhpStorm: PHP IDE and Code Editor from JetBrains: 20/07/2022.

[14] Flowchart Maker & Online Diagram Software: 15/09/2022.

[15] Figma: the collaborative interface design tool.: 20/06/2022.

[16] Eloquent ORM - Laravel - The PHP Framework For Web Artisans: 10/10/2022.

[17]

58