Tunisian Republic

Ministry of Higher Education

and Scientific Research

University of Jendouba

Faculty of Law, Economic and Management

Sciences of Jendouba

Graduation Project Report

In order to obtain

National Diploma of «Business computing»

Speciality : Business information system

By

Cherni Dhia Elhak

Design and development of an application for

managing F-KONZEPT file

Host company : Sebn TN

Academic supervisor : Mme Ghazouani Wided

Company supervisor : Mr Abidi Ramzi
Member of the Jury : Mme Selmi Mouna
Member of the Jury : Mme Mabrouk Olfa

Academic year : 2022-2023

Dedications

From the depth of my heart, I dedicate this work to all those who are dear to me

To the Memory of my dear grandmother

I cannot express my deep sorrow in your absence. I wish you could have been with me today.

To my dear mother

For her love and support, and for believing in me and standing on my side whatever the
situation is.

To my dear uncle

Your advices and encouragements would always be my sources of guidance and hope through
all my life.

To my dear aunts

Who have always believed in me and supported me in every step I take.

And of course, to all my friends, my source of joy and strive, for the exceptional moments and
unlimited care and support.

Finally, to everyone who contributed in making this project a reality.

Dhia

ii
Acknowledgements

I would like to thank anyone who has contributed to the development of this

work, the result of a three-month effort at Sebn-TN.

Foremost, I want to convey my sincere gratitude toward my academic supervisor,

Mme. Ghazouani Wided for her precious guidance, her valuable suggestions, her

patience and her constant availability, which enabled me to complete this project.

I must express my very profound gratitude to my supervisor Mr. Abidi Ramzi,

for his assistance, his support, his relevant advice and his direct and friendly
supervision during this internship.

I take this opportunity to thank the honorable members of the jury for agreeing
to review this work, hoping that this report reflects the quality of the work

carried out during this graduation project.

I would also like to take the opportunity to thank my teachers at the Faculty of
Law, Economic and Management Sciences of Jendouba for considerably

contributing to my professional and academic development.

This accomplishment would not have been possible without you all. Thank you.

iii
Contents

General Introduction 1

1 Presentation of the project frame 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Project presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Host organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
[Link] Historic (Significant events) . . . . . . . . . . . . . . . . . . . . . . . . 5
[Link] Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
[Link] Company organization chart . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Context of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Study of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 National scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 International scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Criticism of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Adopted methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.1 Choice of the appropriate methodology . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.2 Used development approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.3 Modeling language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Analysis and specification of requirements 15

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Scrum team roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Identification of actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Identification of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Global Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Tasks flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iv
 2.8 Project management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.2 Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.3 Project delivery teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.9 Project deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.10 Project risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.11 Work Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.11.1 Hardware Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.11.2 Software Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
[Link] Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
[Link] Technologies and frameworks . . . . . . . . . . . . . . . . . . . . . . . 29
2.12 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.12.1 Logical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.12.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.12.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
[Link] Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
[Link] Package diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Study and realization of sprint 1 36

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Use case diagram of sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3 Task board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.4 Sprint Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Sprint design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.1 Static design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.2 Dynamic design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Sprint realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5 Sprint testing and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

v
4 Study and realization of sprint 2 62
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.1 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.2 Use case diagram of sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.3 Task board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.4 Sprint Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Sprint design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.1 Static design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3.2 Dynamic design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4 Sprint realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.5 Sprint testing and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5 Study and realization of sprint 3 90

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2.1 Sprint 3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2.2 Use case diagram of sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.3 Task board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.4 Sprint Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3 Sprint design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.1 Static design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.2 Dynamic design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4 Sprint realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.5 Sprint testing and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

General conclusion 105

Bibliography 106

vi
Annexes 108
Annexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

vii
List of Figures

1.1 Groups of sumitomo electric bordnetze around the world [2] . . . . . . . . . . . . . . . 4

1.2 SEBN TN logo [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Wiring harness contains approximately 778 components . . . . . . . . . . . . . . . . . 6
1.4 Company organization chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Interface of nanonets website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Interface of klippa website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Scrum Framework cycle [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Scrum team [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Global use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Tasks flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Visual Studio Code logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 GanttProject logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Laragon logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8 StartUML logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.9 Overleaf logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.10 Html5 logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.11 Css3 logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.12 Javascript logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.13 Php logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.14 Laravel logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.15 Bootstrap logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.16 PostgreSQL logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.17 The 3-tier architecture [24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.18 MVC concept [26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.19 Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.20 Package diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1 Sprint 1 use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2 Sprint 1 task board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Authenticate use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

viii
List of Figures

3.4 Manage users use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.5 Profile management use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Class diagram of sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.7 Authenticate sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.8 Add user sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.9 Modify user sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.10 Delete user sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.11 Consult sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.12 Consult profile sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.13 Modify profile sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.14 Authenticate activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.15 Delete user activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.16 Administrator table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.17 Planner table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.18 Technician table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.19 Authenticate interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.20 Add user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.21 Modify user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.22 Delete user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.23 Consult user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.24 Modify profile interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.25 Consult profile interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.1 Sprint 2 use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2 Sprint 2 use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3 Manage tasks use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4 Review tasks use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5 Identification use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 Class diagram of sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.7 Add task sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.8 Modify task sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.9 Delete task sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.10 Consult task sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.11 Checkmark task sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

ix
List of Figures

4.12 Consult task sequence diagram(technician) . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.13 Pipes identification sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.14 Operation mode identification sequence diagram . . . . . . . . . . . . . . . . . . . . . . 79
4.15 Buffer identification sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.16 Modify task activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.17 Pipes identification activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.18 Tasks table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.19 Connectors table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.20 Wires table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.21 Add task interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.22 Modify task interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.23 Delete task interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.24 Consult task interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.25 Checkmark task interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.26 Consult task interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.27 Pipes identification interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.28 Buffer identification interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.29 Operation mode identification interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.1 Sprint 3 use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2 Sprint 3 task board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3 Transform file use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4 Manage transformed file use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 Track history use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.6 Class diagram of sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.7 Transform file sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.8 Modify file sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.9 Consult file sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.10 Consult login activities sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.11 Transform file activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.12 Consult file activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.13 History table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.14 Transform file interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.15 Consult file interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

x
5.16 Modify file interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.17 Consult login activities interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Annexe 1.1 Application likability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Annexe 1.2 Application feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

xi
List of Tables

1.1 Denotations and Connotations (nanonets) . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Denotations and Connotations (klippa) . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Comparative table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Comparative table of different methodologies . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Members of the project using the Scrum framework . . . . . . . . . . . . . . . . . . . . 13

2.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Project delivery team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Project deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Project risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Material characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 Backlog of sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2 Backlog of authenticate use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Backlog of add user use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Backlog of modify user use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5 Backlog of delete user use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6 Backlog of consult user use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7 Backlog of modify profile use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8 Backlog of consult profile use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9 Data dictionary of the “admins” table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.10 Data dictionary of the “planners” table . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.11 Data dictionary of the “technicians” table . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.12 Testing and validation of sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.1 Backlog of sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2 Backlog of add task use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3 Backlog of modify task use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Backlog of consult task use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.5 Backlog of delete task use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.6 Backlog of consult tasks use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.7 Backlog of checkmark tasks use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

xii
4.8 Backlog of pipes identification use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9 Backlog of Operation mode identification use case . . . . . . . . . . . . . . . . . . . . . 70
4.10 Backlog of buffer identification use case . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.11 Data dictionary of the “tasks” table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.12 Data dictionary of the “wires” table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.13 Data dictionary of the “boms” table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.14 Testing and validation of sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.1 Backlog of sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.2 Backlog of transform file use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3 Backlog of consult file use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.4 Backlog of modify file use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.5 Backlog of consult login activities use case . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.6 Data dictionary of the “history” table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.7 Testing and validation of sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

xiii
List of Abbreviations

• ERP = Enterprise resource planning

• GmbH = is an abbreviation of the German phrase “Gesellschaft mit beschränkter Haftung”

• MRP = Material requirement planning

• UML = Unified Modeling Language

xiv
General Introduction

In recent years, new information and communication technologies have evolved exponentially,
They have contributed to the evolution and improvement of various IT disciplines across multiple
domains. one of the domains that evolved rapidly because of information technology, is the industrial
field.

Moreover, industrial activities getting more and more sophisticated, and companies have multiple
needs in terms of productivity and industrial performance, under the classic constraints of budget and
deadlines, while ensuring an acceptable cost for the customer. Therefore, to remain competitive, it is
essential to automate systems that perform repetitive tasks and save time.

In this way, and to confirm it’s presence on a national and international scale and maintain
it’s position among the leaders on the market of automotive electrical cable producers, Sebn TN has
deployed the technological means to automate some of IT department tasks.

The main objective of this project is to develop an application for managing F-KONZEPT file
which facilitates for employees the interaction with data inside it and to provide a feasible environment
to perform some tasks in shorter time.
This report presents the different stages of the realization of this project and will be spread over five
chapters and end with general conclusion:
• Chapter 1 (Presentation of the project frame): An introductory chapter in which we make
a brief presentation of the host company and the project. Then, we present the study of the
existing project and the proposed solution and the design method adopted.

• Chapter 2 (Analysis and specification of requirements): The second chapter called project
preparation defines the realization of this work with the Scrum methodology. We also identify
the functional needs in a Product Backlog and we define the sprint schedule. Subsequently, we
specify the functional needs illustrated by use case diagrams with a few scenarios followed by a
specification of the non-functional needs of our application and the initialization of the project
and the implementation of the development environment, the architecture as well as the hardware
and software environment.

1
General Introduction

• Chapter 3 (Study and realization of sprint 1): This chapter is to present the first Sprint
from which we will develop the analysis, design, implementation and functional tests.

• Chapter 4 (Study and realization of sprint 2): This chapter is to present the second Sprint
from which we will develop the analysis, design, implementation and functional tests.

• Chapter 5 (Study and realization of sprint 3): This chapter is to present the third Sprint
from which we will develop the analysis, design, implementation and functional tests.

• General conclusion: Finally, we end this report with a general conclusion in which we outline
the results achieved and we outline the possible perspectives of this project.

2
 Chapter 1

Presentation of the project frame

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Project presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Study of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Criticism of the existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Adopted methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 1. Presentation of the project frame

1.1 Introduction

we will present in what follows the host organization in which our internship took place ,its services
and products. then, we will move to the study of the existing solution where we will do a detailed
analysis of the existing solutions, count it’s limits and propose an alternative solution. finally , we will
end this chapter with a presentation of the adopted project management methodology.

1.2 Project presentation

1.2.1 Host organization

Sumitomo Electric Bordnetze (SEBN) is a global automotive supplier with approximately 40,000
employees in 14 countries. The product portfolio includes electrical systems and electrical and electronic
components for conventional and electric drive technologies, including, among others, multi-voltage and
high-voltage wiring harnesses [1].

Figure 1.1: Groups of sumitomo electric bordnetze around the world [2]

4
Chapter 1. Presentation of the project frame

[Link] Historic (Significant events)

• 1986 : Establishment of the company as a joint venture between Volkswagen AG and Siemens
and given the name Volkswagen Bordnetze GmbH.

• 1990 : The first international locations were built up ,in turkey.

• 1992 : Set up a subsidiary in Poland.

• 1993 : The firm took the responsibilities of developing golf 4.

• 1996 : Set up a subsidiary in slovakia.

• 2001 : Set up a subsidiary in Morocco.

• 2003 : Creation of the joint venture "Changchun Volkswagen Bordnetze" in Changchun with
the aim of covering the Chinese market.

• 2006 : –Volkswagen AG and Siemens AG sell Volkswagen Bordnetze GmbH. It was acquired by
Sumitomo Electric Industries and Sumitomo Wiring Systems.

– The official name change to Sumitomo Electric Bordnetze.

– Set up a subsidiary in Ukraine.

• 2008 : Set up a subsidiary in Tunisia.

Figure 1.2: SEBN TN logo [3]

5
Chapter 1. Presentation of the project frame

[Link] Activities

SEBN TN is the supplier of the German leader in the automotive industry: Volkswagen. The company
Specialized in the production of electrical wires for the automotive industry vehicles belonging to the
Volkswagen group: SEAT, SKODA and Passat B8 [4].

Figure 1.3: Wiring harness contains approximately 778 components

[Link] Company organization chart

Figure 1.4: Company organization chart

6
Chapter 1. Presentation of the project frame

The company hires more than 4,000 employees (directors, supervisors and workers). There are
three work shifts per day:

• Shift from 6:00 a.m. to 2:00 p.m.

• Shift from 2:00 p.m. to 10:00 p.m.

• Shift from 10:00 p.m. to 6:00 a.m.

Each team changes its schedule from one week to another in parallel with the quality control
department. All these teams are led and supervised by a production supervisor.

1.2.2 Context of the project

This project is part of the graduation project that conclude our Bachelor’s degree in business computing
,Specialty "business information system".
Our project consists in designing and developing an integrated web application within the
Sumitomo Electric Bordnetze TN. it consists of displaying, extracting the technical data provided by
the customer in form of a matrix of automotive wiring components according to the options of the
car in a well-defined excel format and transforming those data in another format which facilitates its
massive introduction to the ERP system.

1.2.3 Problem statement

Production planning is done according to the customer order, the logistics department uses these orders
using SAP software to determine the quantities of raw materials needed according to the MRP method.
Preparation of these orders is done by Planning Department (PPE). This department mainly
focus on the technical documentation, the list of components, the operating mode or the method of
work in the area with the aim of achieving the following objectives:

• Develop production processes

• Analyze and translate customer modifications

• Assess feasibility and implement customer/internal changes.

• Optimize costs / product development time

7
Chapter 1. Presentation of the project frame

This department faces several difficulties, due to the large amount of data and its complexity ,
the extraction process take long time since it is done manually, also because of its ambiguity it could
causes human errors ,which results in a loss of resources and time.

1.3 Study of the existing

Before starting to plan our application, we will present an analysis of some existing similar applications.

1.3.1 National scale

On the national scale there are no applications that handle the problem at hand.

1.3.2 International scale

Nanonets:

AI-based intelligent document processing with Nanonets self-learning OCR. Automate data capture
from invoices, receipts, passports, ID cards and more [5].

Figure 1.5: Interface of nanonets website

8
Chapter 1. Presentation of the project frame

Functional analysis:

• Use AI to read unseen, semi-structured documents

• Eliminate tedious data entry

• Quickly validate data captured from the document

• Support conversion to multiple types of documents

Technical analysis:

In the Table table below, we present the denotations and connotations of Nanonets platform.

Denotations Connotations

Homepage is arranged in vertical parts Services provided are shown clearly

Colors used : Blue Blue: Blue is often associated with sadness in the
English language. Blue is also used extensively to
represent calmness and responsibility.

Website Link [Link]

Table 1.1: Denotations and Connotations (nanonets)

Klippa:

Founded in 2015, Klippa’s goal is to digitize and automate administrative processes with modern
technologies [6].

Figure 1.6: Interface of klippa website

9
Chapter 1. Presentation of the project frame

Functional analysis:

• Fast text recognition and data extraction

• Convert documents from / to various formats

• Automatically parse documents for useful data

• Automated data discovery and inventory

Technical analysis:

In the Table table below, we present the denotations and connotations of klippa platform.

Denotations Connotations

Homepage is arranged in vertical parts Precise vision of website components

Colors used : Green Green: is a very down–to–earth color. It can

represent new beginnings and growth. It also
signifies renewal and abundance. Alternatively,
green can also represent envy or jealousy, and a
lack of experience.

Website Link [Link]

Table 1.2: Denotations and Connotations (klippa)

1.4 Criticism of the existing

After studying some feedback solutions on the market, the table below presents a comparative study
according to several criteria.

Nanonets klippa

Excel files support limited limited

Security medium strong

Performance excellent good

Table 1.3: Comparative table

10
Chapter 1. Presentation of the project frame

1.5 Proposed Solution

After extensive research on existing technologies, we have found that applications are somehow limited
,potentially insecure or far too expensive. Therefore, we offer an application "F-KONZEPT" ,which
allows user to have clear and detailled vision of components extracted from an excel file, taking into
account the performance, usability and security.

1.6 Adopted methodology

The strategy used to complete a project is a critical step in promoting and accelerating the fulfilment
of a software system’s functions. there are several project management techniques ,many of which are
arrangments and hybrids of various system.

With so many options ,how can we choose the best technique for our team and project ?

1.6.1 Choice of the appropriate methodology

In order to build the best method ,we must first define our project objectives and priorities.
We noticed that the planning department (PPE) have a significant desire for a solution in shortest
feasible period, therefore we picked the agile technique to meet them by swifly and consistenly delivering
features with high added value and adjusting to unforeseen changes requested through feedback.
After decideing to use agile development management ,we must select the best strategy or framework
for our project.
indeed the number of agile methods/frameworks avaible might be confusing, we have conducted a
comparison between the differnt agile methods/frameworks in the table below:

Method Pros Cons

XP

• Excellent design and software • It is difficult to achieve

• A high degree of quality as a result • Designing gradually is difficult

of thorough testing of all elements
• Development based on code
• Test cases that are simple to grasp
• There is no design documentation

11
Chapter 1. Presentation of the project frame

SCRUM

• Time and money are saved • If team members are unaware,

the project will fail or never be
• The project’s implementation is
completed
visible
• If a need is not clearly specified,
• Customer input is ongoing
it is impossible to predict project
• It is easier to offer a high-quality costs and timelines
product

RUP

• Respond to consumer demands as • Customization-is-frequently

soon as possible expensive

• Deliverables are Monitored and • Slower and less adaptive

maintained
• Vision is neither instant nor evident
• Architecture based on Components

Table 1.4: Comparative table of different methodologies

1.6.2 Used development approach

Following an in-depth examination of the various approaches and current Agile frameworks, we selected
the Scrum development framework, which provides more visibility on the project and allows for faster
integration of changes. The Scrum framework is built on three pillars:

• Transparency: All aspects of the project in progress must have clear and objective definitions.
These concepts should be shared by all participants so that everyone speaks the same language
when doing their respective jobs. This information must also be freely accessible and disseminated
on a regular basis.

12
Chapter 1. Presentation of the project frame

• Adaptation: The notion of incremental iterations comes into play during adaptation; if an
inspection reveals that any of the features that ensure customer pleasure are not being carried
out as specified by the requirements, the process or the product must be modified.

• Inspection: Inspections should be performed on a regular basis to ensure that the progress
accomplished thus far matches to the project’s objectives and the demands of the end customer.

Figure 1.7: Scrum Framework cycle [7]

Distribution of roles:
The table below depicts the various project members according to the Scrum framework:

Role Mission Member

Product Owner Responsible for giving the team a vision of the Mr Ramzi abidi
product

Scrum Master Responsible for making sure that scrum works and Mme Wided ghazouani
how it should be applied

Developers Responsible of developing project Dhia elhak cherni

Table 1.5: Members of the project using the Scrum framework

13
Chapter 1. Presentation of the project frame

1.6.3 Modeling language

We used UML as the modeling language for this project to model our project system.
UML is a general-purpose, developmental modeling language in the area of software engineering and
it’s designed to give a common way to depict a system’s architecture.

1.7 Conclusion

Throughout this chapter, we have been able to situate the general context of our end of studies project,
namely the host organization and the major objectives to be taken into account. in addition, we carried
out a study of the existing system and a complete analysis of the adapted solution while specifying the
methodological choice of development.

14
 Chapter 2

Analysis and specification of

requirements

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Scrum team roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Identification of actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Identification of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Global Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7 Tasks flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Project management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9 Project deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

10 Project risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

11 Work Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

12 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 2. Analysis and specification of requirements

2.1 Introduction

After initially presenting the function and feasibility of our system, in this chapter we will prepare and
set up everything necessary for the project launch .
it’s about identify the actors, to analyze the needs by specifying the functional and non-functional
needs, to create the Backlog of the product to have a better vision on the project, to define all the
needs in the form of a use case diagram global and plan sprints.

2.2 Scrum team roles

Scrum is a framework for project management commonly used in software development. It’s designed
for teams of ten or fewer members who break their work into goals that can be completed within
time-boxed iterations, called sprints.
The Scrum team chiefly consist of three roles: The Scrum Master, Product Owner and the Development
Team [8].

Product Owner : Mr abidi ramzi, his role is to ensure the provision of characteristics and
functions of the product to be developed and the approval for the product to be delivered.

Scrum Master : Mme Ghazouani Wided, her role is help the scrum team avoid or remove
impediments to its progress also coaching the team, within the scrum principles, in order to deliver
high-quality features for the product.

Development team : Cherni Dhia elhak, the developers carry out all work required to build
increments of value every sprint. Development team may include one or more peoples.

16
Chapter 2. Analysis and specification of requirements

Figure 2.1: Scrum team [9]

2.3 Identification of actors

An actor represents a role played by an external entity (human user, hardware device or other system)
which interacts directly with the studied system.
In the context of our analysis, the actors we were able to identify are:

Administrator : This profile has the advantage of managing planners and technicians accounts.
In addition to that, manage tasks, track history, also update his/her profile.

Technician : Its function is to update his/her profile, Review tasks and identification.

Planner : Its function is to update his/her profile, manage the file and transform it.

2.4 Identification of requirements

In this section, we will expose the functional and non-functional needs of our application.

17
Chapter 2. Analysis and specification of requirements

2.4.1 Functional Requirements

• To authenticate : The security of our system is a key factor in our project. Indeed, in order
to access their sessions, users have a unique ID and a password allowing them to authenticate
themselves.

• Manage users (administrator): This privilege is only authorized to the administrator, This
can be done via the admin interface.

• Profile management (administrator): administrator has the ability to modify his/her own
information.

• Track history (administrator): administrator has the ability to check history, and track who
logged in.

• Manage tasks (administrator): administrator assign tasks to the Technician, and this last
have to fulfill those tasks.

• Transform file (Planner): Planner has the ability to transform the excel file into accessible
database, and it’s the planner main function.

• Manage transformed file (Planner): planner can check transformed file, also can modify it.

• Profile management (Planner): planner has the ability to modify his/her own information.

• Review tasks (Technician): Technician can check tasks assigned to him/her and checkmark
once complete it.

• Identification (Technician): Every technician is required to perform some tasks, these tasks
are : buffer identification, operation mode identification and pipes identification.

• Profile management (Technician): Technician has the ability to modify his/her own information.

18
Chapter 2. Analysis and specification of requirements

2.4.2 Non-Functional Requirements

The non-functional requirements describe the properties that the system should have. In the following,
we will detail the non-functional requirements that our solution must meet:

• Usability : The application must be easy to use and provide a simple and understandable
interface.

• Security : Our application contains sensitive information, so it must comply with the rules
relating to the security of computer systems. We need to have a secure access system based on
authentication.

• Performance : Quick response time and fast processing time.

2.5 Product backlog

The Product Backlog is the central point of any Scrum project. It is a given list of everything that
might be required in the product and is the unique source of requirements for all changes to be made
to the product.
We describe in this section the product backlog of our project, illustrated by the table below:

– ID : It’s a unique number and auto-incremented by each user story.

– Feature : Use case name.

– User story : This is a short description of the task to be performed.

– Priority : Defines the order of execution.

– Complexity : It’s a value that estimates the complexity.

∗ 3 = Very complex

∗ 2 = Moderately complex

∗ 1 = Little complex

ID Feature User story Priority Complexity

1 Authenticate As-an-(administrator/Technician/ planner), High priority 3

I-need-to-authenticate-to-ensure-a-secure
connection.

19
Chapter 2. Analysis and specification of requirements

2 Manage users As an administrator, I can add a new High priority 3

(planner/Technician).
As an administrator, I can modify a High priority 3
(Technician/planner). information.
As an administrator, I can delete a Medium 2
(Technician/planner). priority
As an administrator, I can consult Medium 1
(Technician/planner) information. priority

3 Manage tasks As an administrator, I can create a new task High priority 2

and assign to a technician.
As an administrator, I can modify the task. High priority 2
As an administrator, I can delete the task. Medium 2
priority
As an administrator, I can consult the task. High priority 1

4 Profile As an (administrator/Technician/ planner), I Low priority 1

management can consult my profile.
As an (administrator/Technician/planner), I High priority 3
can modify my profile information.

5 Track history As an administrator i can check logins history. High priority 3

6 Transform file As a planner i can transform the file by High priority 3

uploading it into a database.

7 Manage As-a-planner,-i-can-check-file-after High priority 2

transformed transforming it.
file
As a planner, i can modify file after High priority 3
transforming it.

8 Review tasks As a Technician, I can consult my tasks. High priority 1

As a Technician, I can checkmark the task High priority 2
once i finish.

20
Chapter 2. Analysis and specification of requirements

9 Identification As a technician i can identify pipes High priority 3

identification.
As a technician i can identify operation mode. High priority 3
As a technician i can identify buffer. High priority 3

Table 2.1: Product Backlog

2.6 Global Use Case Diagram

Use case diagrams are used to provide a global vision of the functionalities of a software system. They
allow collecting, analyze and organize the needs, and to identify the main functionalities of a system.
It is the first UML step of a system analysis. Indeed, it is a representation of the interaction of a
user (actor) and the system (use case) without worrying about the way the system will execute the
described functionalities. The global use case diagram, represented by figure 2.2, represents the global
functionalities offered by our application.

Figure 2.2: Global use case diagram

21
Chapter 2. Analysis and specification of requirements

2.7 Tasks flowchart

Figure 2.3: Tasks flowchart

2.8 Project management

In this part, we present first of all a sub-planning which represents the way of dividing our project,
then the Gantt chart and ending with the project implementation team.

2.8.1 Planning

This section presents how the project was divided into tasks to ensure its smooth running.
Divide of the project: During the conceptual period of our project and after the planning and the
elaboration of the specifications, I started the realization of my future application but in a split way.
with that being said, I divide the realization of the application into modules (sprint) with deliverables,
so that at the end I can have a complete project to deliver.
I divide the realization of the application into modules (sprint) with deliverables, so that at the end
I can have a complete project to deliver. So for that, we have to split the project on the number of
modules that represent sprints. We followed a relevant work path which takes place for two weeks for
training on agile methods and the collection of information which has the role of searching for similar
applications, then we divided our work into three sprints and each sprint contains 3 cases.
We devoted 7 days for each sprint regarding the specification of functional needs, the design, the
realization as well as the test and validation.

22
Chapter 2. Analysis and specification of requirements

2.8.2 Gantt chart

The Gantt chart, commonly used in project management, is one of the most effective tools for visually
representing the progress of the different activities (tasks) that make up a project.
This diagram therefore makes it possible to visualize at a glance[10] :

• The different tasks to consider.

• The start date and end date of each task.

• The expected duration of each task.

• The possible overlapping of tasks, and the duration of this overlapping.

The start date and end date of the project as a whole In summary, a Gantt chart lists all the
tasks to be done to complete the project, and indicates the date by which these tasks must be done
(the schedule) Figure “2.4” presents project planning using “Gantt Project” software.

Figure 2.4: Gantt chart

23
Chapter 2. Analysis and specification of requirements

2.8.3 Project delivery teams

Name Role

Dhia elhak cherni Intern / Developer

Wided ghazouani Supervisor / Scrum Master

Ramzi abidi Company responsible / Product Owner

Table 2.2: Project delivery team

Explanation of the mission of each of the actors in the project:

Developer:

• Development of the project management file.

• Realization of the detailed specification.

• Coding.

• Performing unit tests.

Scrum Master:

• Validates the functional specifications file.

• Validate the coding.

• Validate the deliverables.

• Check compliance with requests.

24
Chapter 2. Analysis and specification of requirements

Product Owner:

• Presents the needs of the project.

• Provide a clear vision of the product and define its characteristics.

• Accept or reject the product at the end of each Sprint.

• Ensures that the team focuses on the items of the Backlog with the highest added value.

• Reports on acceptance of deliverables.

2.9 Project deliverables

Phase Deliverables Responsible

Needs study Needs analysis and specification Dhia elhak cherni

Analysis and conception UML Diagrams Dhia elhak cherni

Coding and testing Web application Dhia elhak cherni

Documentation Project report Dhia elhak cherni

Table 2.3: Project deliverables

2.10 Project risk

The risks Type Impact on the project Corrective actions

Incompatible operating Non-Blocking Risk Issues in deployment phase Change the operating
systems-with-the system of my computer
company systems

Table 2.4: Project risk

2.11 Work Environment

Throughout the realization of our project, we have used particular hardware and software that we will
present in the following sections.

25
Chapter 2. Analysis and specification of requirements

2.11.1 Hardware Environment

To carry out the realization, we used as hardware environment, a workstation with the following
characteristics:

Component Characteristic

Brand DELL inspiron 3580

Processor Intel(R) core (TM) i5-8265u CPU @ 1.60GHz 1.80GHz

Ram 8.00 GB

Operating system Windows 10 pror

System type 64-bit operating system, x64 based processor

Table 2.5: Material characteristics

2.11.2 Software Environment

[Link] Tools

We will list in this section the different software solutions that were used during the implementation
of our mobile application.

• Visual Studio Code : is a lightweight but powerful source code editor which runs on your
desktop and is available for Windows, macOS and Linux. It comes with built-in support for
JavaScript, TypeScript and [Link] and has a rich ecosystem of extensions for other languages
and runtimes (such as C++, C#, Java, Python, PHP, Go, .NET) [11].

Figure 2.5: Visual Studio Code logo

26
Chapter 2. Analysis and specification of requirements

• GanttProject : GanttProject is an open-source project management application for Windows,

macOS and Linux desktops. It is written in Java and Kotlin and includes contributions from
hundreds of people all around the world [12].

Figure 2.6: GanttProject logo

• Laragon : Laragon is a portable, isolated, fast, and powerful universal development environment
for building and managing various web applications based on PHP, [Link], Python, Go, and
Ruby. Laragon has an isolated environment with your OS and doesn’t use Windows services.
It has its own service orchestration, which manages services asynchronously. Laragon starts
instantly and uses low RAM while running. [13].

Figure 2.7: Laragon logo

27
Chapter 2. Analysis and specification of requirements

• StarUML : Is a software engineering tool for system modeling using the Unified Modeling
Language, as well as Systems Modeling Language, and classical modeling notations. It is
published by MKLabs and is available on Windows, Linux and MacOS [14].

Figure 2.8: StartUML logo

• Overleaf : Is a collaborative cloud-based LaTeX editor used for writing, editing and publishing
scientific documents [15].

Figure 2.9: Overleaf logo

28
Chapter 2. Analysis and specification of requirements

[Link] Technologies and frameworks

• HTML5 : (Hypertext Markup Language) is a markup language used for structuring and
presenting content on the World Wide Web. It is the fifth and final major HTML version
that is a World Wide Web Consortium (W3C) recommendation [16].

Figure 2.10: Html5 logo

• Css3 : (Cascading Style Sheets) is a style sheet language used for describing the presentation
of a document written in a markup language such as HTML or XML (including XML dialects
such as SVG, MathML or XHTML). CSS is a cornerstone technology of the World Wide Web,
alongside HTML and JavaScript [17].

Figure 2.11: Css3 logo

29
Chapter 2. Analysis and specification of requirements

• Javascript : Often abbreviated as JS, is a programming language that is one of the core
technologies of the World Wide Web, alongside HTML and CSS. As of 2022, 98% of websites
use JavaScript on the client side for webpage behavior, often incorporating third-party libraries.
All major web browsers have a dedicated JavaScript engine to execute the code on users devices
[18].

Figure 2.12: Javascript logo

• Php : A popular general-purpose scripting language that is especially suited to web development.
Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites
in the world [19].

Figure 2.13: Php logo

30
Chapter 2. Analysis and specification of requirements

• Laravel : Is a free and open-source PHP web framework, intended for the development of
web applications following the model–view–controller (MVC) architectural pattern and based on
Symfony. Some of the features of Laravel are a modular packaging system with a dedicated
dependency manager, different ways for accessing relational databases, utilities that aid in
application deployment and maintenance, and its orientation toward syntactic sugar [20].

Figure 2.14: Laravel logo

• Bootstrap : Powerful, extensible, and feature-packed frontend toolkit. Build and customize
with Sass, utilize prebuilt grid system and components, and bring projects to life with powerful
JavaScript plugins [21].

Figure 2.15: Bootstrap logo

31
Chapter 2. Analysis and specification of requirements

• PostgreSQL : Also known as Postgres, is a free and open-source relational database management
system (RDBMS) emphasizing extensibility and SQL compliance. It was originally named
POSTGRES, referring to its origins as a successor to the Ingres database developed at the
University of California, Berkeley. In 1996, the project was renamed to PostgreSQL to reflect
its support for SQL. After a review in 2007, the development team decided to keep the name
PostgreSQL and the alias Postgres [22].

Figure 2.16: PostgreSQL logo

2.12 Architecture

In any IT project, choosing the right architecture is a fundamental step in order to create a functional
application that meets the needs. In this section, we focus on the overall design of our solution. For
this, we begin by presenting the physical architecture and then the logical architecture.

2.12.1 Logical architecture

The identification of the System components (and their dependencies) that deliver the software services
required to achieve the business goals criteria for deployment is referred to as logical architecture.
Logical Architecture is the technique and documentation used to provide a more accurate, comprehensive,
and clear description of system components by providing well-defined interfaces and component specifications,
as well as essential architectural procedures[23].
Below we will describe 3-tiers architecture:

32
Chapter 2. Analysis and specification of requirements

• A client that requests a resource via a user interface (usually a web browser) responsible for
presenting the resource.

• An application server (called middleware) which provides the resource, but calls on the resources
of another server.

• A data server which provides the application server with the resources required to respond to
the client, on which procedures are stored.

Figure 2.17: The 3-tier architecture [24]

2.12.2 Software Architecture

The Model-View-Controller (MVC) is an architectural pattern that separates an application into three
main logical components: the model, the view, and the controller. Each of these components are built
to handle specific development aspects of an application. MVC is one of the most frequently used
industry-standard web development framework to create scalable and extensible projects [25].
Below we will describe the three segments of this model:

Figure 2.18: MVC concept [26]

33
Chapter 2. Analysis and specification of requirements

2.12.3 Conception

[Link] Deployment diagram

A deployment diagram is a UML diagram type that shows the execution architecture of a system,
including nodes such as hardware or software execution environments, and the middleware connecting
them. Deployment diagrams are typically used to visualize the physical hardware and software of a
system. Using it you can understand how the system will be physically deployed on the hardware [27].

Figure 2.19: Deployment diagram

[Link] Package diagram

Package diagram, a kind of structural diagram, shows the arrangement and organization of model
elements in middle to large scale project. Package diagram can show both structure and dependencies
between sub-systems or modules, showing different views of a system, for example, as multi-layered
(aka multi-tiered) application - multi-layered application model [28].

34
Chapter 2. Analysis and specification of requirements

Figure 2.20: Package diagram

2.13 Conclusion

During this chapter we have identified the different actors within our project, defined the different
functional and non-functional requirements, presented the architecture and the technological choices.
We also established the planning of our project and prepared the site for the realization of the sprints
that will follow, by establishing the planning of these. We will now proceed with our first sprint in the
following chapter.

35
 Chapter 3

Study and realization of sprint 1

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 Sprint design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Sprint realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Sprint testing and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapter 3. Study and realization of sprint 1

3.1 Introduction

In this chapter we will present the first sprint of the project, The study of this sprint covers the analysis,
the design, the realization, and the functional tests.

3.2 Functional specification

This part aims to develop the first sprint with the following functional specifications: Sprint 1 Backlog,
Sprint 1 Use Case Diagram, task board and Sprint Analysis.

3.2.1 Sprint 1 Backlog

A sprint is a short period of time of fixed duration during which a certain number of activities will
follow one another and end with the delivery of a working product increment.
In this part we will present the Backlog of sprint 1 which corresponds to a list of expected features of
a sprint.
The following table defines the stories in our Sprint One Product Backlog.

ID Functions Task Start date End date Responsible

1 Authenticate 15/2/2023 22/2/2023

2 Manage users Add(planner/Technician)
Modify(planner/Technician) 23/2/2023 2/3/20233
Delete(planner/Technician) Dhia
Consult(planner/Technician)
3 Profile management Consult(administrator 3/3/2023 10/3/2023
/Technician/planner)
Modify(administrator
/Technician/planner)

Table 3.1: Backlog of sprint 1

37
Chapter 3. Study and realization of sprint 1

3.2.2 Use case diagram of sprint 1

Figure 3.1: Sprint 1 use case diagram

3.2.3 Task board

The task board is a physical presentation of the sprint backlog allowing everyone to know the progress
of the sprint developments. It is composed of 3 columns:

• To do: list of tasks to be processed (a task is a development element of a User Story)

• In progress: list of tasks under development

• Completed: completed task list

38
Chapter 3. Study and realization of sprint 1

Figure 3.2: Sprint 1 task board

3.2.4 Sprint Analysis

In this part we present the analysis phase which answers the question “what does the system do”. The
answer to this question results in the presentation of the use case diagram and then the text description
of each of them.

• Authenticate

Figure 3.3: Authenticate use case diagram

39
Chapter 3. Study and realization of sprint 1

Description of the use case authenticate:

Use case Authenticate

Actors Administrator
Planner
Technician

Purpose Authenticate the user and to log in to the application

Preconditions User must have an account

Post conditions User logged in to the application

Nominal scenario 1. The user accesses the login interface.

2. The user fill in his/her account ID and password.
3. The user clicks on the Sign In button.
4. The system verify the provided email and password.
5. The system sends the user information and the token.
[Link] system redirect the user to his/her application interface.

Exception E2. User cancel the operation.

[Link] the provided ID or password combination are not correct
then the system will abort the login process.

Table 3.2: Backlog of authenticate use case

40
Chapter 3. Study and realization of sprint 1

• Manage users

Figure 3.4: Manage users use case diagram

Description of the use case add task:

Use case Add user

Actors Administrator

Purpose To create a new user

Preconditions The administrator must be authenticated

User doesn’t exist in the application database

Post conditions User successfully added

Nominal scenario 1. The administrator accesses manage planners or technician

interface.
2. The Administrator fills in all the user personal information.
3. The Administrator clicks on the add button.
4. The system adds the user to the database and displays a
success message.

41
Chapter 3. Study and realization of sprint 1

Exception E3. If the provided email is currently being used with other
account then an error message will appear in the screen

Table 3.3: Backlog of add user use case

Description of the use case modify user:

Use case Modify user

Actors Administrator

Purpose To update user information

Preconditions The administrator must be authenticated

Post conditions User information updated

Nominal scenario 1. The administrator accesses manage planners or technician

interface
2. The administrator consult users list
3. The administrator clicks on modify button and the system
display an edit form
4. The Administrator clicks on the confirm button
5. The system updates the user information in the database
and display success message

Exception E4. The data entered is incorrect or missing so the system

will display an error message

Table 3.4: Backlog of modify user use case

42
Chapter 3. Study and realization of sprint 1

Description of the use case delete user:

Use case Delete user

Actors Administrator

Purpose To delete a user

Preconditions The administrator must be authenticated

At least one user exists

Post conditions User successfully deleted

Nominal scenario 1. The administrator accesses manage planners or technician

interface
2. The administrator consults users list
[Link] Administrator click on the remove button after choosing
the user to delete
4. A confirmation message appears when the user has been
successfully removed

Exception E2. The administrator cancel the operation

Table 3.5: Backlog of delete user use case

Description of the use case consult user:

Use case Consult user

Actors Administrator

Purpose To Consult users

Preconditions The administrator must be authenticated

At least one user exists

Post conditions User logged in to the application

Nominal scenario 1. The administrator accesses manage planners or technician

interface
2. The administrator consults users list

Exception E1. system display an empty list

Table 3.6: Backlog of consult user use case

43
Chapter 3. Study and realization of sprint 1

• Profile management

Figure 3.5: Profile management use case diagram

Description of the use case modify profile:

Use case Modify profile

Actors Administrator
Planner
Technician

Purpose To update profile information

Preconditions The User must be authenticated

Post conditions Profile information updated

Nominal scenario 1. the user accesses manage profile interface

2. The user edits his/her information
3. The user clicks on modify button
4. The system display success message

Exception E3. System display error message due to wrong information

Table 3.7: Backlog of modify profile use case

44
Chapter 3. Study and realization of sprint 1

Description of the use case consult profile:

Use case Consult profile

Actors Administrator
Planner
Technician

Purpose To consult profile information

Preconditions The User must be authenticated

Post conditions Display profile information

Nominal scenario 1. the user accesses manage profile interface

Exception

Table 3.8: Backlog of consult profile use case

3.3 Sprint design

3.3.1 Static design

• Class diagram

Class diagrams are one of the most useful types of diagrams in UML as they clearly map out
the structure of a particular system by modeling its classes, attributes, operations, and relationships
between objects [29].

45
Chapter 3. Study and realization of sprint 1

Figure 3.6: Class diagram of sprint 1

• Data dictionary

Attribute Signification Data type Obligation Size key constraints

id admin unique identifier bigint yes 20 primary

email admin email varchar yes 255

password admin password varchar yes 255

nom admin name varchar yes 255

prenom admin family name varchar yes 255

photo admin picture varchar yes 255

Table 3.9: Data dictionary of the “admins” table

46
Chapter 3. Study and realization of sprint 1

Attribute Signification Data type Obligation Size key constraints

id planner unique identifier bigint yes 20 primary

nom planner name char yes 50

prenom planner family name char yes 50

email planner email varchar yes 255

password planner password varchar yes 255

matricule planner matricule int yes 10

telephone planner mobile number int yes 10

poste planner poste varchar yes 255

statut planner statut varchar yes 255

zone planner zone varchar yes 255

Date_embauche planner Hiring date date yes 255

photo planner picture varchar yes 255

Table 3.10: Data dictionary of the “planners” table

Attribute Signification Data type Obligation Size key constraints

id technician unique bigint yes 20 primary

identifier

nom technician name char yes 50

prenom technician family name char yes 50

email technician email varchar yes 255

password technician password varchar yes 255

matricule technician matricule int yes 10

telephone technician mobile number int yes 10

pecialite technician specialite varchar yes 255

Date_embauche technician hiring date date yes 255

hoto technician picture varchar yes 255

Table 3.11: Data dictionary of the “technicians” table

47
Chapter 3. Study and realization of sprint 1

3.3.2 Dynamic design

• Sequence diagram

Sequence diagrams are a popular dynamic modeling solution in UML because they specifically
focus on lifelines, or the processes and objects that live simultaneously, and the messages exchanged
between them to perform a function before the lifeline ends [30].

Sequence diagram of authenticate use case:

Figure 3.7: Authenticate sequence diagram

48
Chapter 3. Study and realization of sprint 1

Sequence diagram of add user use case:

Figure 3.8: Add user sequence diagram

49
Chapter 3. Study and realization of sprint 1

Sequence diagram of modify user use case:

Figure 3.9: Modify user sequence diagram

50
Chapter 3. Study and realization of sprint 1

Sequence diagram of delete user use case:

Figure 3.10: Delete user sequence diagram

51
Chapter 3. Study and realization of sprint 1

Sequence diagram of consult use case:

Figure 3.11: Consult sequence diagram

Sequence diagram of consult profile use case:

Figure 3.12: Consult profile sequence diagram

52
Chapter 3. Study and realization of sprint 1

Sequence diagram of consult profile use case:

Figure 3.13: Modify profile sequence diagram

• Activity diagram

An activity diagram is essentially a flowchart that shows activities performed by a system [31].

53
Chapter 3. Study and realization of sprint 1

Activity diagram of authenticate use case

Figure 3.14: Authenticate activity diagram

54
Chapter 3. Study and realization of sprint 1

Activity diagram of delete user use case:

Figure 3.15: Delete user activity diagram

55
Chapter 3. Study and realization of sprint 1

3.4 Sprint realization

3.4.1 Database

Administrator table:

Figure 3.16: Administrator table

Planner table:

Figure 3.17: Planner table

56
Chapter 3. Study and realization of sprint 1

Technician table:

Figure 3.18: Technician table

3.4.2 Interfaces

Authentication interface:

Figure 3.19: Authenticate interface

57
Chapter 3. Study and realization of sprint 1

Add user interface:

Figure 3.20: Add user interface

Modify user interface:

Figure 3.21: Modify user interface

58
Chapter 3. Study and realization of sprint 1

Delete user interface:

Figure 3.22: Delete user interface

Consult user interface:

Figure 3.23: Consult user interface

Modify profile interface:

Figure 3.24: Modify profile interface

59
Chapter 3. Study and realization of sprint 1

Consult profile interface:

Figure 3.25: Consult profile interface

3.5 Sprint testing and validation

Testing a software is a consistent process that aims to ensure the proper functioning of the system
through a comparison of expected behaviors and the results obtained. Before the end of the test of
each sprint, let’s test the functionality of the module. Then, we have elaborated in the following table
a set of cases of functional test scenarios relating to sprint 1.

Test cases Testing approach Aim Result

Authenticate enter email and password then access private space of each user conform
click on login button

Add user fill in the form then click on display add form and add user conform
add button

Modify user access user list and click on display modify form and modify conform
modify button user

Delete user access user list and click on display user list and delete user conform
remove button

Consult user access user list display user information conform

Consult access profile management access profile information conform

profile interface

Modify profile access profile management display profile information and conform
interface-and-modify modify it
information

Table 3.12: Testing and validation of sprint 1

60
Chapter 3. Study and realization of sprint 1

3.6 Conclusion

In this chapter, we have presented the construction of the first sprint, namely Authentication, manage
users, profile management, We have focused on its functional specification and design, and then we
presented some interfaces. The next chapter illustrates the life cycle of the second sprint.

61
 Chapter 4

Study and realization of sprint 2

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3 Sprint design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 Sprint realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5 Sprint testing and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Chapter 4. Study and realization of sprint 2

4.1 Introduction

In this chapter, we will present the second sprint which is composed of the three use cases.
Indeed, we will study this sprint case by case. Then, we will approach the design, the realization and
the functional tests of each case.

4.2 Functional specification

This part aims to develop the second sprint with the following functional specifications: Product
Backlog, Sprint 2 Use Case Diagram, Task Board and Sprint Analysis.

4.2.1 Sprint 2 Backlog

The following table defines the stories in our Sprint 2 Product Backlog.

ID Functions Task Start date End date Responsible

1 Add task
Manage tasks Modify task 11/3/2023 18/3/2023
Delete task
Consult tasks
2 Review tasks Consult tasks 19/3/2023 26/3/2023 Dhia
Checkmark task
3 Pipes identification
Identification Operation-mode 27/3/2023 3/4/2023
identification
Buffer identification

Table 4.1: Backlog of sprint 2

63
Chapter 4. Study and realization of sprint 2

4.2.2 Use case diagram of sprint 2

Figure 4.1: Sprint 2 use case diagram

4.2.3 Task board

Figure 4.2: Sprint 2 use case diagram

64
Chapter 4. Study and realization of sprint 2

4.2.4 Sprint Analysis

• Manage task

Figure 4.3: Manage tasks use case diagram

Description of the use case add task:

Use case Add task

Actors Administrator

Purpose To create a new task

Preconditions The administrator must be authenticated

Post conditions Task successfully added

Nominal scenario 1. The administrator accesses manage tasks interface

2. The administrator chooses the task name and the
technician who will perform it
3. The administrator clicks on the add button
4. The system adds the task to the database and displays a
success message

65
Chapter 4. Study and realization of sprint 2

Exception

Table 4.2: Backlog of add task use case

Description of the use case modify task:

Use case Modify task

Actors Administrator

Purpose To modify task

Preconditions The administrator must be authenticated

Post conditions Task successfully modified

Nominal scenario 1. The administrator accesses manage tasks interface and list
tasks
2. The Administrator chooses the task to modify
3. The Administrator modify the task
4. The system asks for confirmation
5. The administrator confirms the modification
6. The system updates the task and display success message

Exception

Table 4.3: Backlog of modify task use case

Description of the use case consult task:

Use case Consult task

Actors Administrator

Purpose To consult task

Preconditions The administrator must be authenticated

Post conditions Display tasks

Nominal scenario 1. The administrator accesses the list of tasks

2. The system displays the task list
3. The administrator consults task list

Exception

Table 4.4: Backlog of consult task use case

66
Chapter 4. Study and realization of sprint 2

Description of the use case delete task:

Use case Delete task

Actors Administrator

Purpose To delete a task

Preconditions The administrator must be authenticated

Post conditions Task successfully deleted

Nominal scenario 1. The administrator accesses manage tasks interface and list
tasks
2. The Administrator chooses the task to delete
3. The Administrator click on delete button
4. The system asks for confirmation
5. The administrator confirms the deleting
6. The system display success message

Exception

Table 4.5: Backlog of delete task use case

• Review tasks

Figure 4.4: Review tasks use case diagram

67
Chapter 4. Study and realization of sprint 2

Description of the use case consult tasks:

Use case Consult tasks

Actors Technician

Purpose To consult tasks

Preconditions The Technician must be authenticated

Post conditions Display tasks

Nominal scenario 1. The technician accesses to the list of tasks

2. The system displays the task list
3. The technician consults task list

Exception

Table 4.6: Backlog of consult tasks use case

Description of the use case checkmark task:

Use case Checkmark tasks

Actors Technician

Purpose To checkmark a task

Preconditions The Technician must be authenticated

Post conditions Display tasks list after checkmark

Nominal scenario 1. The technician accesses to the list of tasks

2. The system displays the task list
3. The technician choose the task to checkmark

Exception

Table 4.7: Backlog of checkmark tasks use case

68
Chapter 4. Study and realization of sprint 2

• Identification

Figure 4.5: Identification use case diagram

Description of the use case Pipes identification tasks:

Use case Pipes identification

Actors Technician

Purpose To identify pipes

Preconditions The Technician must be authenticated

Post conditions Display Information about the required wire

Nominal scenario 1. The technician accesses identification interface

2. The technician enter the number of wire to identify
3. Click identify pipe button
4. New interface displayed with information of the wire

Exception E3. Show an error message if the number entered is wrong

Table 4.8: Backlog of pipes identification use case

69
Chapter 4. Study and realization of sprint 2

Description of the use case Operation mode identification tasks:

Use case Operation mode identification

Actors Technician

Purpose To identify Operation mode

Preconditions The Technician must be authenticated

Post conditions Display Operation mode of required wire

Nominal scenario 1. The technician accesses identification interface

2. The technician enter the number of wire to identify the
operation mode to manufacture it
3. Click identify operation mode button
4. New interface displayed with information of the begin and
the end of wire during manufacturing

Exception E3. Show an error message if the number entered is wrong

Table 4.9: Backlog of Operation mode identification use case

Description of the use case buffer identification tasks:

Use case Buffer identification

Actors Technician

Purpose To identify buffer

Preconditions The Technician must be authenticated

Post conditions Display Information about the manufacturing specification

Nominal scenario 1. The technician accesses identification interface

2. The technician enter the number of wire to identify it
manufacturing specifications
3. Click identify buffer
4. New interface displayed with information of the wire
manufacturing specification

Exception E3. Show an error message if the number entered is wrong

Table 4.10: Backlog of buffer identification use case

70
Chapter 4. Study and realization of sprint 2

4.3 Sprint design

4.3.1 Static design

• Class diagram

Figure 4.6: Class diagram of sprint 2

71
Chapter 4. Study and realization of sprint 2

• Data dictionary

Attribute Signification Data type Obligation Size key constraints

id task unique identifier bigint yes 20 primary

technicien_id id of technicien bigint yes 20

titre task title varchar yes 255

descreption task descreption text yes 255

date task creation date date yes 255

etat task status varchar yes 50

Table 4.11: Data dictionary of the “tasks” table

Attribute Signification Data type Obligation Size key

constraints

id Auto-increment-unique bigint yes 20 primary

identifier

numr_AEM Wire number varchar yes 255

numr_LTG Wire reference varchar yes 255

famille Wire family varchar yes 255

transfert_de_Ltg Transfer-to-another varchar yes 255

family

Lieu_affectation Wire affectation sector varchar yes 255

Liste_de_SP Wire list name varchar yes 255

Soudage Welding type varchar yes 255

Isolation Insulation with bandage varchar yes 255

Tachete Change wire color varchar yes 255

Hybride Wire hybrid varchar yes 255

Remarque Note about wire varchar yes 255

Numero_variante Wire variant number varchar yes 255

Nom_variante Variant name varchar yes 255

nom_de_projet Project name varchar yes 255

Nom_debut Wire name(start) varchar yes 255

72
Chapter 4. Study and realization of sprint 2

Numr_de_pin Wire number(start) varchar yes 255

coordoonees Coordination(start) varchar yes 255

Numr_de_contact Number of contact (start) varchar yes 255

seal Seal (start) varchar yes 255

Nom2 Wire name(end) varchar yes 255

Numr_de_pin2 Wire number(end) varchar yes 255

coordoonées2 Coordination(end) varchar yes 255

Numr_de_contact2 Number of contact (end) varchar yes 255

seal2 Seal (end) varchar yes 255

Numr_de_Bobine Reel number varchar yes 255

Fil_torsade wire twisted type varchar yes 255

Longeur Wire length varchar yes 255

Couleur Wire color varchar yes 255

Section Wire section varchar yes 255

V1 production section 1 varchar yes 255

V2 production section 2 varchar yes 255

V3 production section 3 varchar yes 255

V4 production section 4 varchar yes 255

Table 4.12: Data dictionary of the “wires” table

Attribute Signification Data type Obligation Size key

constraints

id Connector unique identifier bigint yes 20 primary

nom Connector name varchar yes 255

coordoones Connector coordination varchar yes 255

description Connector description varchar yes 255

connecteur Connector type varchar yes 255

Table 4.13: Data dictionary of the “boms” table

73
Chapter 4. Study and realization of sprint 2

4.3.2 Dynamic design

• Sequence diagram

Sequence diagram of add task use case:

Figure 4.7: Add task sequence diagram

74
Chapter 4. Study and realization of sprint 2

Sequence diagram of modify task use case:

Figure 4.8: Modify task sequence diagram

75
Chapter 4. Study and realization of sprint 2

Sequence diagram of delete task use case:

Figure 4.9: Delete task sequence diagram

Sequence diagram of consult task use case:

Figure 4.10: Consult task sequence diagram

76
Chapter 4. Study and realization of sprint 2

Sequence diagram of checkmark task use case:

Figure 4.11: Checkmark task sequence diagram

Sequence diagram of consult task use case(technician):

Figure 4.12: Consult task sequence diagram(technician)

77
Chapter 4. Study and realization of sprint 2

Sequence diagram of pipes identification use case:

Figure 4.13: Pipes identification sequence diagram

78
Chapter 4. Study and realization of sprint 2

Sequence diagram of operation mode identification use case:

Figure 4.14: Operation mode identification sequence diagram

79
Chapter 4. Study and realization of sprint 2

Sequence diagram of buffer identification use case:

Figure 4.15: Buffer identification sequence diagram

80
Chapter 4. Study and realization of sprint 2

• Activity diagram

Activity diagram of modify task use case:

Figure 4.16: Modify task activity diagram

81
Chapter 4. Study and realization of sprint 2

Activity diagram of pipes identification use case:

Figure 4.17: Pipes identification activity diagram

82
Chapter 4. Study and realization of sprint 2

4.4 Sprint realization

4.4.1 Database

Tasks table:

Figure 4.18: Tasks table

Connectors table:

Figure 4.19: Connectors table

83
Chapter 4. Study and realization of sprint 2

Wires table:

Figure 4.20: Wires table

4.4.2 Interfaces

Add task interface:

Figure 4.21: Add task interface

84
Chapter 4. Study and realization of sprint 2

Modify task interface:

Figure 4.22: Modify task interface

Delete task interface:

Figure 4.23: Delete task interface

85
Chapter 4. Study and realization of sprint 2

Consult task interface:

Figure 4.24: Consult task interface

Checkmark task interface:

Figure 4.25: Checkmark task interface

86
Chapter 4. Study and realization of sprint 2

Consult task interface:

Figure 4.26: Consult task interface

Pipes identification interface:

Figure 4.27: Pipes identification interface

87
Chapter 4. Study and realization of sprint 2

Buffer identification interface:

Figure 4.28: Buffer identification interface

Operation mode identification interface:

Figure 4.29: Operation mode identification interface

88
Chapter 4. Study and realization of sprint 2

4.5 Sprint testing and validation

Test cases Testing approach Aim Result

Add task fill in the form then click on display add form and add task conform
add button

Modify task fill in the form then click on display modify form and modify conform
modify button task

Delete task access user list and click on Display task list and delete task conform
delete button

Consult-task Access task list Display task list conform

(administrator)

Consult-task Access task list Display task list conform

(technician)

Checkmark task Click on checkbox of the task Check completed task conform

Pipes Insert wire number And click Display wire information conform
identification on pipes identification button

Operation mode Insert wire number And click Display the begin and the end of conform
identification on buffer identification button wire during production

Buffer Insert wire number And click Display wire details with set-up conform
identification on buffer identification button

Table 4.14: Testing and validation of sprint 2

4.6 Conclusion

In this chapter, we have presented the construction of the second sprint, namely Manage tasks, Review
tasks and identification, we have focused on its functional specification and design, and then we
presented some interfaces. The next chapter illustrates the life cycle of the third sprint.

89
 Chapter 5

Study and realization of sprint 3

Plan
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

2 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3 Sprint design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4 Sprint realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5 Sprint testing and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 5. Study and realization of sprint 3

5.1 Introduction

In this chapter, we will present the third sprint which is composed of three use cases.
Indeed, we will study this sprint case by case. Then, we will approach the design, the realization and
the functional tests of each case.

5.2 Functional specification

This part aims to develop the third sprint with the following functional specifications: Sprint 3 Backlog,
Sprint 3 Use Case Diagram, Table of tasks and Sprint Analysis.

5.2.1 Sprint 3 Backlog

The following table defines the stories in our Sprint 3 Product Backlog.

ID Functions Task Start date End date Responsible

1 Transform file 4/4/2023 11/4/2023

2 Manage transformed file Consult file 12/4/2023 19/4/2023 Dhia
Modify file
3 Track history Consult login activities 20/4/2023 27/4/2023

Table 5.1: Backlog of sprint 3

91
Chapter 5. Study and realization of sprint 3

5.2.2 Use case diagram of sprint 3

Figure 5.1: Sprint 3 use case diagram

5.2.3 Task board

Figure 5.2: Sprint 3 task board

92
Chapter 5. Study and realization of sprint 3

5.2.4 Sprint Analysis

• Transform file

Figure 5.3: Transform file use case diagram

Description of the use case transform file:

Use case Transform file

Actors Planner

Purpose To upload excel file to database

Preconditions The planner must be authenticated.

An excel file to upload

Post conditions File uploaded successfully

Nominal scenario 1. The planner accesses upload file interface.

2. The planner clicks on upload button.
3. The planner choose file to upload.
4. Planner click on confirm button.
5. The system display success message.

Exception E4. File format not supported

Table 5.2: Backlog of transform file use case

93
Chapter 5. Study and realization of sprint 3

• Manage transformed file

Figure 5.4: Manage transformed file use case diagram

Description of the use case consult file:

Use case Consult file

Actors Planner

Purpose To consult data uploaded from the file

Preconditions The planner must be authenticated

Post conditions Display data

Nominal scenario 1. The planner accesses manage file interface

2. The planner click on check file button
3. The system display the data
4. The planner consult the data

Exception

Table 5.3: Backlog of consult file use case

94
Chapter 5. Study and realization of sprint 3

Description of the use case modify file:

Use case Modify file

Actors Planner

Purpose To modify uploaded data

Preconditions The planner must be authenticated

Post conditions File modified successfully

Nominal scenario 1. The planner accesses manage file interface and data
2. The planner consult data and choose which to be modified
3. The planner click on modify button
4. The planner modify desired information
5. The planner clicks on the confirm button
6. The system updates the data and display success message

Exception

Table 5.4: Backlog of modify file use case

• Track history

Figure 5.5: Track history use case diagram

95
Chapter 5. Study and realization of sprint 3

Description of the use case consult login activities:

Use case Consult login activities

Actors Administrator

Purpose To check users login

Preconditions The administrator must be authenticated

Post conditions Display record of login

Nominal scenario 1. The administrator accesses track history interface

2. The system display login activities list

Exception

Table 5.5: Backlog of consult login activities use case

5.3 Sprint design

5.3.1 Static design

• Class diagram

Figure 5.6: Class diagram of sprint 3

96
Chapter 5. Study and realization of sprint 3

• Data dictionary

Attribute Signification Data type Obligation Size key

constraints

id_record record unique identifier bigint yes 20 primary

record_date login date date yes 255

id_emplyee Id of employee varchar yes 255

nom_employee Name of epmloyee varchar yes 255

matricule_employee Matricule of employee varchar yes 255

Table 5.6: Data dictionary of the “history” table

5.3.2 Dynamic design

• Sequence diagram

Sequence diagram of Transform file use case:

Figure 5.7: Transform file sequence diagram

97
Chapter 5. Study and realization of sprint 3

Sequence diagram of modify file use case:

Figure 5.8: Modify file sequence diagram

98
Chapter 5. Study and realization of sprint 3

Sequence diagram of consult file use case:

Figure 5.9: Consult file sequence diagram

Sequence diagram of consult login activities use case:

Figure 5.10: Consult login activities sequence diagram

99
Chapter 5. Study and realization of sprint 3

• Activity diagram

Activity diagram of Transform file use case:

Figure 5.11: Transform file activity diagram

100
Chapter 5. Study and realization of sprint 3

Activity diagram of consult file use case:

Figure 5.12: Consult file activity diagram

101
Chapter 5. Study and realization of sprint 3

5.4 Sprint realization

5.4.1 Database

History table:

Figure 5.13: History table

5.4.2 Interfaces

Transform file interface:

Figure 5.14: Transform file interface

102
Chapter 5. Study and realization of sprint 3

Consult file interface:

Figure 5.15: Consult file interface

Modify file interface:

Figure 5.16: Modify file interface

Consult login activities interface:

Figure 5.17: Consult login activities interface

103
Chapter 5. Study and realization of sprint 3

5.5 Sprint testing and validation

Test cases Testing approach Aim Result

Transform file Upload file by choosing a file Upload data inside an excel file into Conform
and click on upload button database

Consult file Access manage file interface Display data uploaded into Conform
and click on check file button database

Modify file Access manage file interface, Modify the data uploaded inside Conform
consult file and click on modify database
button then edit it

Consult login Access track history interface Display login records Conform
activities

Table 5.7: Testing and validation of sprint 3

5.6 Conclusion

During this chapter, we introduced the third sprint. To do so, we went through the specifications, the
design, and the realization then we end with testing.

104
General conclusion

This internship that I carried out within the company SEBN TN in engineering department is a part of
the end-of-study project ,to obtain the fundamental degree in busniess compting ,speciality "business
information system".

In this context, I had the opportunity to design and develop an application for managing the
F-KONZEPT file. It’s main goal is to help employees manage data inside an excel file taht contain
information about the specifications of products (wires) ,and automate some tasks.
moreover it was a profitable opportunity for me to discover the work inside a large company, and gain
rich experience in the automotive wiring field and to discover its details, its elements, constraints...

To achieve our objective we started by understanding the general context of the project and
the different requirements of the future system, then we tried to build our application incrementally
by using the agile Scrum methodology.
Then we identify the functional and non-functional needs, we prepared the Product Backlog for very
precise details of the tasks of the application.

Despite the changes and issues that we encountered during the internship, in development,
design and materials, we were able to achieve all the objectives present.

Finally, our work won’t stop at this level, we will continue to work on the project and finish the
features not yet developed such exporting data in different format ,enhance the security ,and improve
user interfaces and performance.

105
Bibliography

[1] “Sebn.” (2023), [Online]. Available: [Link]

Bordnetze.

[2] “Titre de l’article.” (2023), [Online]. Available: [Link]

[3] “Titre de l’article.” (2023), [Online]. Available: [Link]

sumitomo-electric-tunisia-2/.

[4] “Titre de l’article.” (2023), [Online]. Available: [Link]

e-bordnetze-tunisia.

[5] “Titre de l’article.” (2023), [Online]. Available: [Link]

[6] “Titre de l’article.” (2023), [Online]. Available: [Link]

[7] “Titre de l’article.” (2023), [Online]. Available: https : / / www . bocasay . com / scrum - method -
benefits-web-development/.

[8] “Titre de l’article.” (2023), [Online]. Available: [Link]

roles-responsibilities/.

[9] “Titre de l’article.” (2023), [Online]. Available: [Link]

roles-responsibilities/.

[10] “Titre de l’article.” (2023), [Online]. Available: [Link]

[11] “Titre de l’article.” (2023), [Online]. Available: [Link]

[12] “Titre de l’article.” (2023), [Online]. Available: [Link]

[13] “Titre de l’article.” (2023), [Online]. Available: [Link]

[14] “Titre de l’article.” (2023), [Online]. Available: [Link]

[15] “Titre de l’article.” (2023), [Online]. Available: [Link]

[16] “Titre de l’article.” (2023), [Online]. Available: [Link]

[17] “Titre de l’article.” (2023), [Online]. Available: [Link]

[18] “Titre de l’article.” (2023), [Online]. Available: [Link]

[19] “Titre de l’article.” (2023), [Online]. Available: [Link]

[20] “Titre de l’article.” (2023), [Online]. Available: [Link]

[21] “Titre de l’article.” (2023), [Online]. Available: [Link]

106
Bibliography

[22] “Titre de l’article.” (2023), [Online]. Available: [Link]

[23] “Titre de l’article.” (2023), [Online]. Available: [Link]

logical-architecture.

[24] “Titre de l’article.” (2023), [Online]. Available: [Link]

m_Mise- en- place- dune- architecture- 3- tiers- avec- base- de- donnees- centralisee-
[Link].

[25] “Titre de l’article.” (2023), [Online]. Available: https : / / www . tutorialspoint . com / mvc _
framework/mvc_framework_introduction.htm.

[26] “Titre de l’article.” (2023), [Online]. Available: https : / / www . educative . io / answers / mvc -
explained.

[27] “Titre de l’article.” (2023), [Online]. Available: [Link]

diagram-tutorial/.

[28] “Titre de l’article.” (2023), [Online]. Available: [Link] [Link]/guide/

uml-unified-modeling-language/what-is-package-diagram/.

[29] “Titre de l’article.” (2023), [Online]. Available: https : / / www . lucidchart . com / pages / uml -
class-diagram.

[30] “Titre de l’article.” (2023), [Online]. Available: https : / / www . lucidchart . com / pages / uml -
sequence-diagram.

[31] “Titre de l’article.” (2023), [Online]. Available: https : / / www . lucidchart . com / pages / uml -
activity-diagram.

107
Annexes

Annexe

The questionnaire survey is a methodological observation tool that includes a set of questions linked
together in a structured and logical way.
This type of survey aims to obtain quantifiable and comparable statistical data.

Application likability

Application feasibility

108
Annexes

PÌl›
r wybmk˜ wlˆ ¨ TyFAF± TOrl˜ TF Cd˜ T§Ahž Š¤rK› ¨ Š¤rKm˜ @¡ ŸymS œ , £An§
C A› Pylt˜
@¡ œ . T¤dn ‘rOt˜ ¤ T§ AOt’¯ ¤ TyžwžAq˜ wl`˜ Tyl• ¨ šAmˆ± A›wl`› A\ž , ‘rOt˜ ¨ TqbWm˜
ºAKž Y˜ ‘dh§ ©@˜ ¤ Ty¶Arhk˜ ©ztyž Cw w›wty›wF T•rK˜ ™ £@yfn œ ¨l §Cd CAV ¨ ™m`˜
§w˜ r§wW AŒ˜ Ÿ› Tˆwm›  dtF œ . ‰ynOt˜ P¶AO ©wt ¨t˜ Aflm˜ ­C  Ÿyl›A`l˜ ms§ “ybW
™m`˜ @¡ «
dq˜ .£Anrt’ ©@˜ “ybWt˜ “yqt˜ r wybm• › r –˜@•¤

Résumé
Pour résumer ce que nous avons vu, ce projet s’inscrit dans le projet de fin d’études de la
Licence Fondamentale en informatique de gestion (LFIAG), spécialité Système d’Information
d’Entreprise (bis) à la Faculté de Droit, des Sciences Economiques et de Gestion de Jendouba (
FSJEGJ). Ce travail s’est déroulé dans le cadre d’un stage effectué au sein de la Sebn TN qui vise
à mettre en place une application permettant aux salariés de gérer le dossier F-KONZEPT. Un
ensemble de langages de développement web, ainsi que des logiciels ont été utilisés pour réaliser
l’application que nous avons proposée.

Abstract
To summarize what we have seen, this project is included in the end-of-study project for the Fun-
damental License in business computing (LFIAG), specialty business Information System (BIS)
at the Faculty of Law, Economic and Management Sciences of Jendouba (FSJEGJ). This work
took place within the frame of an internship carried out within the Sebn TN which aims to set up
an application which allows employees to manage F-KONZEPT file. A set of web development
languages, as well as softwares were used to achieve the application that we proposed.

109